如何理解释放块的损坏中缀模式
How to understand corrupted infix pattern for freed block
我们启用了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
---------------------------------------------------------------
非常感谢Matt Peddlesden
在MSDN Library的这篇文章中对它进行了很好的描述。经典的堆损坏错误,您的代码在释放堆块后写入堆块。如果地址重复良好,则可以使用调试器设置数据断点来捕获写入。如果没有,那么你就需要在耳朵之间用这个工具来寻找虫子。
@Hans是对的,这是堆损坏。如果您将appverif配置为捕获堆栈跟踪,则可以看到内存释放的位置。您还可以转储写在"损坏地址"的内容。
这里有一个例子,我的代码多次减少Python对象的引用计数。堆栈指示内存在垃圾回收期间为free
'd。内存转储中"损坏地址"处的f0f0f0ef
表示此伪refcount。
VERIFIER STOP 0000000E: pid 0x5ABC: Corrupted infix pattern for freed heap block.
FD531000 : Heap handle for the heap owning the block.
EE53B4F8 : Heap block being freed.
000001D8 : Size of the heap block.
EE53B508 : Corruption address.
=======================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.
=======================================
(5abc.52dc): Break instruction exception - code 80000003 (first chance)
eax=551402d4 ebx=00000000 ecx=000001a1 edx=000001dc esi=5513ec5c edi=fd531000
eip=551337f9 esp=005ebbc0 ebp=005ebdd4 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
vrfcore!VerifierStopMessageEx+0x599:
551337f9 cc int 3
0:000> dt verifier!_DPH_BLOCK_INFORMATION EE53B4F8-20
+0x000 StartStamp : 0xabcdaaa9
+0x004 Heap : 0x7d531000 Void
+0x008 RequestedSize : 0x1d8
+0x00c ActualSize : 0x200
+0x010 Internal : _DPH_BLOCK_INTERNAL_INFORMATION
+0x018 StackTrace : 0xff555dec Void
+0x01c EndStamp : 0xdcbaaaa9
0:000> dds 0xff555dec
ff555dec ffb57114
ff555df0 0000f802
ff555df4 00200000
ff555df8 54f4b5c6 verifier!AVrfpDphNormalHeapFree+0xb6
ff555dfc 54f49e63 verifier!AVrfDebugPageHeapFree+0xe3
ff555e00 7791f89e ntdll!RtlDebugFreeHeap+0x3c
ff555e04 7788995d ntdll!RtlpFreeHeap+0xd3d
ff555e08 77888bd8 ntdll!RtlFreeHeap+0x758
ff555e0c 5513af7b vrfcore!VfCoreRtlFreeHeap+0x2b
ff555e10 54ef58ea vfbasics!AVrfpRtlFreeHeap+0x11a
ff555e14 54ef72eb vfbasics!AVrfpHeapFree+0x10b
ff555e18 72b2016a MSVCR100!free+0x1c
ff555e1c 1dce003a python27!PyObject_GC_Del+0x3a
ff555e20 1dd89ce0 python27!type_dealloc+0x170
ff555e24 1dd84986 python27!tupledealloc+0x86
ff555e28 1dd89ee4 python27!type_clear+0x44
ff555e2c 1dcdedb7 python27!delete_garbage+0xf7
ff555e30 1dcdf28a python27!collect+0x3fa
ff555e34 1dcdf551 python27!collect_generations+0x51
ff555e38 1dd85ee9 python27!tuple_iter+0x49
ff555e3c 1dd38833 python27!PyObject_GetIter+0x53
ff555e40 1ddbf65a python27!PyEval_EvalFrameEx+0x6ba
ff555e44 1ddc3acd python27!fast_function+0x8d
ff555e48 1ddc39dd python27!call_function+0x30d
ff555e4c 1ddc1583 python27!PyEval_EvalFrameEx+0x25e3
ff555e50 1ddc3acd python27!fast_function+0x8d
ff555e54 1ddc39dd python27!call_function+0x30d
ff555e58 1ddc1583 python27!PyEval_EvalFrameEx+0x25e3
ff555e5c 1ddc3acd python27!fast_function+0x8d
ff555e60 1ddc39dd python27!call_function+0x30d
ff555e64 1ddc1583 python27!PyEval_EvalFrameEx+0x25e3
ff555e68 1ddc27e3 python27!PyEval_EvalCodeEx+0x8e3
0:000> dds
ff555e6c 1dd60b71 python27!function_call+0x101
ff555e70 1dd379aa python27!PyObject_Call+0x4a
ff555e74 1ddc35a2 python27!PyEval_CallObjectWithKeywords+0xf2
ff555e78 00000000
ff555e7c ff793d2c
0:000> dd EE53B4F8
ee53b4f8 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0
ee53b508 f0f0f0ef f0f0f0f0 f0f0f0f0 f0f0f0f0
ee53b518 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0
ee53b528 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0
ee53b538 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0
ee53b548 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0
ee53b558 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0
ee53b568 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0
相关文章:
- 为什么会发生堆损坏
- 具有奇怪重复模板模式的派生类中的成员变量已损坏
- 平均图像时图像损坏
- 如何针对特定情况调试和修复此双自由内存损坏问题
- 为什么C中的通用链表中存储的数据已损坏
- gdb错误:Backtrace已停止:上一帧与此帧相同(堆栈已损坏?)
- C++双重释放或损坏(out)
- 捕获标准输出以压缩并使用 CTRL-C 中断会给出损坏的 zip 文件
- 使用全局声明的向量时,C++双重释放错误/损坏
- 变量周围的堆栈'...'已损坏
- 运行时检查失败 #2 变量"A"周围的堆栈已损坏
- 使用带有链表的堆栈数据结构将中缀转换为后缀
- 检测到堆损坏:在正常块 c++ 动态 2D 数组之后
- 删除字符串后C++检测到堆损坏
- 两个垫子的 OpenCV 数据是相同的,但使用 Mat::at 检索时的值已损坏
- 我可以写入关闭的套接字并强制纠正损坏的管道错误吗?
- 损坏的结构字符数组 - sqlite C++
- 运行时检查失败 #2 - 变量"e"周围的堆栈已损坏。发生
- zlib 膨胀在使用小缓冲区时会损坏
- 如何理解释放块的损坏中缀模式