如何理解已釋放塊的損壞中綴模式

我們啓用了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 
---------------------------------------------------------------

非常感謝馬特Peddlesden

來源

2011-06-21 Matt Peddlesden

正是在這種MSDN Library article描述相當不錯。經典堆腐敗錯誤，您的代碼在釋放後寫入堆塊。如果地址重複很好，那麼可以用調試器設置一個數據斷點來捕獲寫入。如果沒有，那麼你需要在你的耳朵之間使用該工具來捕捉錯誤。

來源

2011-06-21 11:56:26

@Hans是對的，它是堆腐敗。如果您配置appverif來捕獲堆棧跟蹤，您可以看到內存被釋放的位置。您也可以轉儲寫在「腐敗地址」上的內容。

以下是我的代碼太多次減少Python對象的引用計數的示例。堆棧表示在垃圾收集期間內存爲free'd。在「腐敗地址」的內存轉儲中的f0f0f0ef表示這個虛假引用。

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

來源

2017-06-20 22:41:51

如何理解已釋放塊的損壞中綴模式

回答

相關問題