From [email protected] on August 22, 2010 19:39:32
Microsoft Visual C++ Debug Library
Debug Assertion Failed!
Program: e:\derek\ issue251 \base_unittests.exe
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c
Line: 1317
Expression: _CrtIsValidHeapPointer(pUserData)
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press Retry to debug the application)
Abort Retry Ignore
at first I thought it was b/c app_fls_data == priv_fls_data: which is a
bug, so I fixed that (coming from NtContinue path not setting to priv so
got off on next fcache entrance).
0:000> dd 05b39ba0-20
05b39b80 05b39930 05b02840 009cfe98 0000024c
05b39b90 00000214 00000002 00004d9b fdfdfdfd
05b39ba0 000171e4 ffffffff 00000000 00000000
05b39bb0 00000000 00000001 00000000 00000000
05b39bc0 00000000 00000000 00000000 00000000
05b39bd0 00000000 00000000 00000000 00000000
05b39be0 00000000 00000000 00000000 00000000
05b39bf0 00000000 00000000 00000000 009d1960
0:000> ~1s
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=061855d4 edi=06185570
eip=1ea01ec7 esp=061855a8 ebp=061855d8 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
1ea01ec7 a39cd3831d mov [1d83d39c],eax ds:002b:1d83d39c=0000100c
0:001> kn 30
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 061855a4 7d957469 0x1ea01ec7
01 061855d8 7d957615 USER32!DialogBox2+0x20b
02 06185604 7d95c23f USER32!InternalDialogBox+0xdc
03 061858c8 7d95bafb USER32!SoftModalMessageBox+0x972
04 06185a20 7d999609 USER32!MessageBoxWorker+0x26c
05 06185a80 7d982982 USER32!MessageBoxTimeoutW+0x4d
06 06185aa0 7d9996d2 USER32!MessageBoxExW+0x1b
07 06185abc 0076c896 USER32!MessageBoxW+0x18
08 06185b10 0074b13c base_unittests!__crtMessageBoxW+0x216 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtmbox.c @ 158]
09 06187d7c 0076c630 base_unittests!__crtMessageWindowW+0x3bc [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrpt.c @ 363]
0a 0618fe1c 0074ad72 base_unittests!_VCrtDbgReportW+0x8e0 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrptt.c @ 670]
0b 0618fe3c 0074ad3b base_unittests!_CrtDbgReportWV+0x22 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrpt.c @ 241]
0c 0618fe64 007626f9 base_unittests!_CrtDbgReportW+0x2b [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrpt.c @ 258]
0d 0618fe84 00762590 base_unittests!_free_dbg_nolock+0x139 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c @ 1317]
0e 0618febc 0076a35b base_unittests!_free_dbg+0x50 [f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c @ 1258]
0f 0618ff00 7d64abd9 base_unittests!_freefls+0x1eb [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 737]
10 0618ffa8 7d4e069c ntdll!LdrShutdownThread+0x205
11 0618ffb8 7d4e001c kernel32!ExitThread+0x2f
12 0618ffec 00000000 kernel32!BaseThreadStart+0x39
0:001> dt _CrtMemBlockHeader 05b39ba0-20
+0x000 pBlockHeaderNext : 0x05b39930
+0x004 pBlockHeaderPrev : 0x05b02840
+0x008 szFileName : 0x009cfe98 "f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c"
+0x00c nLine : 588
+0x010 nDataSize : 0x214
+0x014 nBlockUse : 2
+0x018 lRequest : 19867
+0x01c gap : [4] "???"
in event_basic_block(tag=0x0076a350)
found call to _free_dbg @0x0076a356 tgt 0x00762540
entering alloc routine 0x00762540 _free_dbg direct pre-retaddr
Error #2
: INVALID HEAP ARGUMENT: _free_dbg 0x05b70310
@0:01:57.657 in thread 127200
0x0076a356 <base_unittests.exe+0x36a356> base_unittests.exe!_freefls
f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c:737
0x7d64abd9 <ntdll.dll+0x4abd9> ntdll.dll!RtlValidateHeap
??:0
0x7d4e069c <KERNEL32.dll+0x2069c> KERNEL32.dll!ExitThread
??:0
0x7d4e001d <KERNEL32.dll+0x2001d> KERNEL32.dll!FlsSetValue
??:0
prior mallocs:
RtlAllocateHeap-post 0x05b700a0-0x05b702d8 = 0x238 (really 0x05b70098-0x05b702e0 0x248)
RtlAllocateHeap-post 0x05b702f0-0x05b70528 = 0x238 (really 0x05b702e8-0x05b70530 0x248)
so the attempted free via _free_dbg is in the middle of Rtl-allocated mem:
yet the dbg header does line up nicely, yet fails the assert.
also:
+0x0cc app_fls_data : 0x00242540
+0x0d0 priv_fls_data : 0x00242540
though in debug build not hitting any fls assert and still hit app assert
the memory sure looks correct:
0:001> dt _tiddata 05b701e0
+0x000 _tid : 0x18660
...
+0x1f8 _encode_ptr : 0x7d627dd1
+0x1fc _decode_ptr : 0x7d627dc6
0:001> U 7d627dd1 L1
ntdll!RtlEncodePointer:
7d627dd1 8bff mov edi,edi
0:001> dt -v _tiddata
struct _tiddata, 47 elements, 0x214 bytes
== 0n532 bytes
the only 0x214 or 532:
_calloc_dbg-post 0x02b61ec0-0x02b620d4 = 0x214 (really 0x02b61ec0-0x02b620d4 0x214)
@@@ unique callstack #6
0x00769e5a <base_unittests.exe+0x369e5a> base_unittests.exe!_mtinit
f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c:395
0x00754d21 <base_unittests.exe+0x354d21> base_unittests.exe!__tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:215
0x00754caf <base_unittests.exe+0x354caf> base_unittests.exe!mainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:181
+0x0cc app_fls_data : 0x00242520
+0x0d0 priv_fls_data : 0x00242520
identical, but neither is DR memory:
0:001> ?? heapmgt->vmheap
struct vm_heap_t
+0x000 start_addr : 0x25230000 ""
+0x004 end_addr : 0x2d230000 ""
though LdrShutdownThread does get the address from fs:fb4 + offs, and
here's our addr a few entries into FlsData (is it an array?):
0:001> dd 00242520
00242520 002428e8 0023af40 00000000 00000000
00242530 04b222e8 05b701e0 00000000 00000000
the thing was allocated here (separate run):
dispatch: target = 0x0076a0e3
Fragment 27734, tag 0x0076a0e3, flags 0x1000030, shared, size 219:
[base_unittests.exe]
app fls: 0x002428e0 0x0023af40 0x00000000 0x02362e38 0x00000000 0x00000000
Entry into F27734(0x0076a0e3).0x1ae1474b (shared)
Exit from sourceless ibl: bb ret [](target 0x0076a0e8 not in cache)
app fls: 0x002428e0 0x0023af40 0x00000000 0x02362e38 0x00000000 0x05b6f078
0:001> U 0076a0e3
base_unittests!_getptd_noexit+0x63 [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 593]:
0076a0e3 83c404 add esp,0x4
0076a0e6 ffd0 call eax
0076a0e8 85c0 test eax,eax
base_unittests!_getptd_noexit+0x27 [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 588]:
588 0076a0a7 6a00 push 0x0
588 0076a0a9 684c020000 push 0x24c
588 0076a0ae 6898fe9c00 push 0x9cfe98
588 0076a0b3 6a02 push 0x2
588 0076a0b5 6814020000 push 0x214
588 0076a0ba 6a01 push 0x1
588 0076a0bc e81f7affff call base_unittests!_calloc_dbg_impl (00761ae0)
588 0076a0c1 83c418 add esp,0x18
588 0076a0c4 8945f8 mov [ebp-0x8],eax
588 0076a0c7 837df800 cmp dword ptr [ebp-0x8],0x0
588 0076a0cb 7459 jz base_unittests!_getptd_noexit+0xa6 (0076a126)
base_unittests!_getptd_noexit+0x4d [f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c @ 593]:
593 0076a0cd 8b4df8 mov ecx,[ebp-0x8]
593 0076a0d0 51 push ecx
593 0076a0d1 8b15b04ea400 mov edx,[base_unittests!__flsindex (00a44eb0)]
593 0076a0d7 52 push edx
593 0076a0d8 a16c1da500 mov eax,[base_unittests!gpFlsSetValue (00a51d6c)]
593 0076a0dd 50 push eax
593 0076a0de e86dfaffff call base_unittests!_decode_pointer (00769b50)
593 0076a0e3 83c404 add esp,0x4
593 0076a0e6 ffd0 call eax
593 0076a0e8 85c0 test eax,eax
_calloc_dbg_impl
_nh_malloc_dbg_impl
_heap_alloc_dbg_impl
_heap_alloc_base
apparently _impl and _base routines are directly called...ugh
Original issue: http://code.google.com/p/drmemory/issues/detail?id=31