C++堆损坏
我已经有一段时间没有做过任何 C++ 了，但决定完成我正在为某人做的一个大项目。我现在收到以下错误消息...
检测到堆损坏：在 0x17DEB940 处的正常块（#1761）之后。 CRT 检测到应用程序在堆缓冲区末尾后写入内存。
我已经逐步完成了我认为可能导致此问题的所有功能，但我不知所措。有没有办法使用更高级的调试功能来解决这个问题？
I haven't done any C++ in a while, but decided to finish a big project I was working on for someone. I am getting the following error message now though...
HEAP CORRUPTION DETECTED: after Normal Block (#1761) at 0x17DEB940.
CRT Detected that the application wrote to memory after end of heap buffer.
I have been stepping through all of the functions I thought might have caused it but I am at a loss. Is there any way using the more advanced debugging features to hunt this down?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这听起来确实像是一个经典的内存损坏错误。该平台将是有用的信息。在没有看到您的代码及其复杂性的情况下，有几种可能性：
我猜测运行时
库将允许您添加对
堆验证代码直接来自
你的代码。我建议放置
调用堆验证代码
代码中的各个位置，以便您
能弄清楚事情的去向
错误的。你会发现这个地方
堆坏了你就会知道
上次通话时没问题。
继续缩小窗口范围，如果
你需要然后检查代码
问题发生的地方。
如果相同的步骤损坏了内存中完全相同的位置，
你应该能够使用你的
调试器设置断点（或观察点）
记忆正在改变。一些
这些改变可能是有意为之的，但是
你应该能够弄清楚
哪个是罪魁祸首。
如果您的代码特别复杂或者重现此代码所需的步骤很长，您可以使用两者的组合 - 缩小有问题的代码部分，然后在损坏的内存位置上放置一个断点。
大卫
It does sound like a classic memory corruption error. The platform would be helpful information. Without seeing your code and it's complexity there are a couple of possibilities:
I'll make a guess that the runtime
library would allow you to add calls to the
heap validation code directly from
your code. I would suggest placing
calls to the heap validation code in
various places in your code so you
can figure out where things go
wrong. You'll find the place where
the heap goes bad and you'll know
that it was ok at the previous call.
Keep narrowing down that window if
you need to and then review the code
where the problem occurs.
If the same steps corrupt exactly the same place in memory,
you should be able to use your
debugger to set a breakpoint (or watchpoint) on the
memory getting changed. Some of
those changes may be intended, but
you should be able to figure out
which one is the culprit.
You might use a combination of the two if your code is particularly complex or the steps needed to reproduce this are long - narrow down a section of code that it problematic and then place a breakpoint on the memory location that gets corrupted.
david
在 Linux 上，我推荐 valgrind 作为一个工具，它可以准确地告诉您出了什么问题。您可以在此处查看一些 Windows 替代方案。
On Linux I would recommend valgrind as a tool that would tell you exactly what went wrong. You may look into some Windows alternatives for it here.
尝试用仪器捕捉它。
听起来有点像经典的 C 错误。您确定在 while 或 for 循环中没有写超出 c 数组（如 int[xyz]）的内容吗？它不会导致任何错误，但是您会在很多与错误所在的部分无关的空间中得到奇怪的效果。 ：p
Try to catch it with Intruments.
Sounds a bit like a classical C error. You are sure you don't write beyond an c array ( like int[xyz]) in a while or for loop? It don't cause any errors, but you get strange effects in a lot spaces that have nothing to do with the part where the bug lives. :p
尝试在启用普通页面堆的情况下使用 AppVerifier。如果您随后将调试器附加到进程，并且运气好的话，堆会损坏，它将在内存块损坏的地方（由于块写入溢出或不足）而中断。只需付出一点努力，您还可以获得分配每个堆块的代码的调用堆栈，这也可以帮助跟踪错误。
不过，跟踪这些错误可能很棘手，有关详细信息，请查看《高级 Windows 调试》一书，其中有一整章专门讨论该主题。
Try using AppVerifier with normal pageheap enabled. If you then attach a debugger to the process and have a heap corruption with some luck it will break at the point where the memory block gets corrupted (by a block write overrun or underrun). With a little effort you can also get a callstack of the code that allocated every heap block, something that can also help to track down the error.
Tracking these errors can be tricky though, for detailed information check the Advanced Windows Debugging book which has a whole chapter devoted to the subject.