Hallo,
trying to run xilinx webpack, after some time a crash happens. I suspect a heap corruption and running with --debugmsg +heap I see quite early
133191 098347d0:Call kernel32.TlsGetValue(00000004) ret=6c371018 133192 trace:heap:RtlAllocateHeap (415d0000,00000002,00000018): returning 415e9068 133193 098347d0:Ret kernel32.TlsGetValue() retval=4037bdf0 ret=6c371018 133194 09830f78:Ret ntdll.RtlAllocateHeap() retval=415e9068 ret=41595068 133195 098347d0:Call user32.GetParent(00010022) ret=6c371331 133196 09830f78:Call ntdll.RtlAllocateHeap(415d0000,00000000,0000000e) ret=41595068 133197 098347d0:Ret user32.GetParent() retval=00000000 ret=6c371331 133198 trace:heap:RtlAllocateHeap (415d0000,00000002,00000018): returning 415e9088 133199 098347d0:Call user32.TranslateMessage(0040735c) ret=6c3711c7 133200 09830f78:Ret ntdll.RtlAllocateHeap() retval=415e9088 ret=41595068 133201 098347d0:Ret user32.TranslateMessage() retval=00000000 ret=6c3711c7 133202 098347d0:Call user32.DispatchMessageA(0040735c) ret=6c3711ce 133203 09830f78:Call ntdll.RtlAllocateHeap(415d0000,00000000,00000016) ret=41595068 133204 warn:heap:HEAP_ValidateInUseArena Heap 40d30000: invalid in-use arena magic for 40d30656 133205 Heap: 40d30000
"invalid in-use arena magic" is an indicator for a corrupy heap. Right?
On each RtlAllocateHeap(), the heap is checked. As the call to RtlAllocateHeap() on line 133196 succeeds, the trashing must have happend between line 133201 and 133203. Right?
Thnaks for any help.
"Uwe" == Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
Uwe> "invalid in-use arena magic" is an indicator for a corrupy Uwe> heap. Right?
Uwe> On each RtlAllocateHeap(), the heap is checked. As the call to Uwe> RtlAllocateHeap() on line 133196 succeeds, the trashing must have Uwe> happend between line 133201 and 133203. Right?
Looking I thinks we have some problem somewhere. Even running calc.exe on a clean tree I get ( wine /dosc/win95/calc.exe --debugmsg +relay,+snoop,+heap,+bitmap,+dib,+x11drv,+bitblt,+cursor > & /tmp/wine.debug"):
3729 0806f2a8:Call x11drv.SetDIBits(403788d8,00000054,00000000,00000020,40809ed4,4037ae50,00000000) ret=40713100 3730 trace:heap:RtlAllocateHeap (40350000,00000002,00000018): returning 4037af08 3731 trace:x11drv:X11DRV_CreateBitmap (00000054) 32x32 1 bpp 3732 trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=1 r=0 g=0 b=0 3733 trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=1/1 r=ff0000 g=ff00 b=ff 3734 trace:bitmap:X11DRV_DIB_SetImageBits XPutImage(46137354,0x8074d80,0x807ea68,0,0,0,0,32,32) 3735 trace:heap:RtlFreeHeap (40350000,00000002,4037af08): returning TRUE 3736 0806f2a8:Ret x11drv.SetDIBits() retval=00000020 ret=40713100 3737 trace:heap:RtlFreeHeap (40350000,00000002,4037ae50): returning TRUE 3738 trace:heap:RtlAllocateHeap (40350000,00000002,00000120): returning 4037af08 3739 trace:bitmap:GetBitmapBits (00000054, 128, 0x4037af14) 32x32 2 colors fetched height: 32 3740 trace:bitmap:GetBitmapBits Calling device specific BitmapBits 3741 0806f2a8:Call x11drv.BitmapBits(00000054,4037af14,00000080,00000002) ret=4070cd33 3742 trace:x11drv:X11DRV_GetBitmapBits (bmp=0x4037aec8, buffer=0x4037af14, count=0x80) 3743 0806f2a8:Ret x11drv.BitmapBits() retval=00000080 ret=4070cd33 3744 trace:bitmap:GetBitmapBits (00000050, 128, 0x4037af94) 32x32 2 colors fetched height: 32 3745 trace:bitmap:GetBitmapBits Calling device specific BitmapBits 3746 0806f2a8:Call x11drv.BitmapBits(00000050,4037af94,00000080,00000002) ret=4070cd33 3747 trace:x11drv:X11DRV_GetBitmapBits (bmp=0x4037ae88, buffer=0x4037af94, count=0x80) 3748 0806f2a8:Ret x11drv.BitmapBits() retval=00000080 ret=4070cd33 3749 0806f2a8:Call x11drv.DeleteObject(00000054) ret=4070d0a1 3750 0806f2a8:Ret x11drv.DeleteObject() retval=00000001 ret=4070d0a1 3751 trace:heap:RtlFreeHeap (40350000,00000002,4037aec8): returning TRUE 3752 0806f2a8:Call x11drv.DeleteObject(00000050) ret=4070d0a1 3753 0806f2a8:Ret x11drv.DeleteObject() retval=00000001 ret=4070d0a1 3754 trace:heap:RtlFreeHeap (40350000,00000002,4037ae88): returning TRUE 3755 trace:heap:RtlAllocateHeap (40350000,00000002,00000018): returning 4037ae50 3756 warn:heap:HEAP_IsRealArena Heap 0x40ba0000: block 0x40790a42 is not inside heap ^^^^^^^^^^^^^^^^^^
Thanks for any help.
On Wed, May 22, 2002 at 05:32:17PM +0200, Uwe Bonnes wrote:
"Uwe" == Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
Uwe> "invalid in-use arena magic" is an indicator for a corrupy Uwe> heap. Right? Uwe> On each RtlAllocateHeap(), the heap is checked. As the call to Uwe> RtlAllocateHeap() on line 133196 succeeds, the trashing must have Uwe> happend between line 133201 and 133203. Right?
Looking I thinks we have some problem somewhere. Even running calc.exe on a clean tree I get ( wine /dosc/win95/calc.exe --debugmsg +relay,+snoop,+heap,+bitmap,+dib,+x11drv,+bitblt,+cursor > & /tmp/wine.debug"):
[...]
3756 warn:heap:HEAP_IsRealArena Heap 0x40ba0000: block 0x40790a42 is not inside heap ^^^^^^^^^^^^^^^^^^
Note that it's called with the WARN case here only !! Might be a problem, or maybe it isn't.
"Andreas" == Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
>> 3756 warn:heap:HEAP_IsRealArena Heap 0x40ba0000: block 0x40790a42 is >> not inside heap ^^^^^^^^^^^^^^^^^^ Andreas> Note that it's called with the WARN case here only !! Might be Andreas> a problem, or maybe it isn't.
Has anybody a clue if this error is important?
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
"Andreas" == Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
>> 3756 warn:heap:HEAP_IsRealArena Heap 0x40ba0000: block 0x40790a42 is >> not inside heap ^^^^^^^^^^^^^^^^^^ Andreas> Note that it's called with the WARN case here only !! Might be Andreas> a problem, or maybe it isn't.
Has anybody a clue if this error is important?
It's not, that's why it is only a warning. In cases where it's a real problem you will get the same message as error, not as warning.
"Uwe Bonnes" bon@elektron.ikp.physik.tu-darmstadt.de wrote:
>> 3756 warn:heap:HEAP_IsRealArena Heap 0x40ba0000: block 0x40790a42 is >> not inside heap ^^^^^^^^^^^^^^^^^^ Andreas> Note that it's called with the WARN case here only !! Might be Andreas> a problem, or maybe it isn't.
Has anybody a clue if this error is important?
Uwe, sorry for the late reply, but I'm certainly sure that warning message above is caused by the HeapValidate calls in windows/winproc.c.