How to understand corrupted infix pattern for freed block

Question

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

score 2 · Accepted Answer · answered Jun 21 '11 at 11:56

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.

score 0 · Answer 2 · answered Jun 20 '17 at 22:41

@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. The f0f0f0ef in the memory dump at the "corruption address" indicates this bogus 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

How to understand corrupted infix pattern for freed block

2 Answers2