异常终止-HeapValidate [英] abend - HeapValidate

问题描述

未处理的异常-用户断点

这是导致此情况的代码:

dhold =(char *)malloc(itdl);

在最终导致问题之前，该代码执行了许多次.遇到问题时，itdl的值为5377.同样，在整个程序中，内存会不断分配，使用和释放.

我假设沿着这条线的某个地方，我已将更多数据移入分配的空间，而我没有足够的空间.我尝试调试并密切注意我使用分配空间的所有位置，但实际上太多的地方和太多的迭代使这一工作变得不可行. (几个小时后我放弃了.)

是否有一些编译选项可以监视存储溢出或有人发现了解决这些问题的巧妙技巧?当然，假设我的问题是存储溢出.还有其他想法为什么简单的malloc会失败?我似乎正在释放完成的空间，因此不太可能(但并非并非不可能)空间用完了.

Unhandled exception - user breakpoint

Here is the code that causes this:

dhold = (char *) malloc(itdl);

This code executes many times before finally causing the problem. The value of itdl is 5377 when the problem is encountered. Also, throughout the program, memory is being continually allocated, used and freed.

I assume that somewhere along the line I have moved more data into an allocated space than I had space for. I have tried debugging and keeping an eye on all of the places I use allocated space but there is simply too many places and far too many iterations to make this practical. (I gave up after several hours.)

Is there some compile option that monitors storage overflow or some clever trick someone has discovered to solve these kinds of problems?Assuming, of course, that my problem is storage overflow. Any other ideas why a simple malloc would fail? I seem to be freeing the space I am finished with so it is unlikely (but perhaps not impossible) that I have run out of space.

推荐答案

断言发生时，您可以中断并查看调用堆栈.
这样应该可以让您对何时发生发生有一个很好的了解.

When the assertion occurs, you can break and look at the call stack.
This should give you a fairly good idea about when this happens.

很容易看出断言发生时是否正在释放所有数据，只需监视其进程的内存消耗即可.在任务管理器中.

请记住，即使您每次都可能释放此内存，程序的其他部分仍可能会变顽皮.

管理缓冲区溢出的一种方法是在缓冲区的末尾添加一个或多个校验字节，为它提供特殊的签名，然后在每次写操作后验证此签名.如果更改，则有人在篡改您的缓冲区.这几乎就是VC检查调试版本中各种溢出/溢出的方式.但是，如果您自己添加处理，则可以随时根据需要验证缓冲区.

您所描述的听起来并不像是缓冲区溢出引起的.但是你永远也不知道.我会开始寻找其他东西.

It''s easy to see if you are freeing all data when the assertion happens by just monitoring its memory consumption of the process in the task manager.

Remember that even though you might be freeing this piece of memory every time, there can be other parts of your program behaving naughty.

One way to manage buffer overruns is to add a check byte (or bytes) to the end of your buffer giving it a special signature, and then validate this signature after every write. If it changes, someone is tampering with your buffer. This is almost how VC checks for various overflows/overruns in debug builds. But if you add the handling yourself you can validate the buffer anytime you want.

What you describe does not sound like it''s originating from a buffer overrun though. But you never know for sure. I would start looking for something else.

这篇关于异常终止-HeapValidate的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！