如何理解已释放块的损坏中缀模式
我们启用了 PageHeap，并在我们的系统上运行 adplus，最近出现了一些“已释放块的中缀模式损坏”故障。
有人可以阐明这意味着什么、代码中可能是什么样子，并建议如何最好地解决问题的步骤吗？
===========================================================
Tue Jun 21 10:55:26.091 2011 (GMT+1): VERIFIER STOP 0000000E: pid 0x1710: corrupted infix pattern for freed block
07751000 : Heap handle
0920A830 : Heap block
00000018 : Block size
0920A844 : corruption address
Tue Jun 21 10:55:26.091 2011 (GMT+1):
===========================================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.
===========================================================
---
--- 1st chance CONTRL_C_OR_Debug_Break exception ----
---------------------------------------------------------------
CTRL-C was pressed to stop debugging this process!
When PageHeap is in use this exception can be an internal exception
---------------------------------------------------------------
非常感谢 马特·佩德尔斯登
We have PageHeap enabled and are running adplus on our system and recently have had a couple of "corrupted infix pattern for freed block" failures.
Can someone shed some light on what this means, what it might look like in the code and suggest steps on how best to proceed with resolving the issue?
===========================================================
Tue Jun 21 10:55:26.091 2011 (GMT+1): VERIFIER STOP 0000000E: pid 0x1710: corrupted infix pattern for freed block
07751000 : Heap handle
0920A830 : Heap block
00000018 : Block size
0920A844 : corruption address
Tue Jun 21 10:55:26.091 2011 (GMT+1):
===========================================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.
===========================================================
---
--- 1st chance CONTRL_C_OR_Debug_Break exception ----
---------------------------------------------------------------
CTRL-C was pressed to stop debugging this process!
When PageHeap is in use this exception can be an internal exception
---------------------------------------------------------------
Many thanks
Matt Peddlesden
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这篇 MSDN 库文章对此进行了很好的描述。经典的堆损坏错误，您的代码在释放后写入堆块。如果地址重复得很好，那么您可以使用调试器设置数据断点来捕获写入。如果没有，那么您将需要用耳朵夹住的工具来追捕该虫子。
It is described pretty well in this MSDN Library article. Classic heap corruption bug, your code is writing to a heap block after it was freed. If the address repeats well then you can set a data breakpoint with the debugger to trap the write. If it doesn't then you'll need the tool between your ears to hunt the bug down.
@Hans 是对的，这是堆损坏。如果您配置了 appverif 来捕获堆栈跟踪，您可以看到内存被释放的位置。您还可以转储“损坏地址”处写入的内容。
下面是一个示例，其中我的代码多次减少了 Python 对象的引用计数。堆栈表明内存在垃圾回收期间被
释放。 “损坏地址”处的内存转储中的f0f0f0ef指示了此伪造的引用计数。@Hans is right, it is heap corruption. If you configured appverif to capture stack traces, you can see where the memory was freed. You can also dump what was written at the "corruption address".
Here's an example where my code was decreasing the reference count on a Python object too many times. The stack indicates that the memory was
free'd during garbage collection. Thef0f0f0efin the memory dump at the "corruption address" indicates this bogus refcount.