ASSERT common/alloc.c:2185: !pt->expect_lib_to_fail || pt->alloc_base == NULL (free() success unexpected)

[derekbruening]

From derek.br...@gmail.com on August 28, 2010 15:30:54

running base_unittests.exe from issue #251 with:
--gtest_filter="-FileVersion*:ProcessUtilTest.GetAppOutput:ReadOnlyFileUtilTest.ContentsEqual:ReadOnlyFileUtilTest.TextContentsEqual:DataPackTest.Load"

...
[----------] 5 tests from ProcessUtilTest
[ RUN ] ProcessUtilTest.SpawnChild
[ OK ] ProcessUtilTest.SpawnChild (203 ms)
[ RUN ] ProcessUtilTest.KillSlowChild
[ OK ] ProcessUtilTest.KillSlowChild (234 ms)
[ RUN ] ProcessUtilTest.SetProcessBackgrounded
[ OK ] ProcessUtilTest.SetProcessBackgrounded (47 ms)
[ RUN ] ProcessUtilTest.EnableLFH
:::Dr.Memory::: ASSERT FAILURE (thread 132132): E:/derek/dr/win32/oss-clients/drmemory/common/alloc.c:2183: !pt->expect_lib_to_fail || pt->alloc_base == NULL (free() success unexpected)

but, can't repro by just running --gtest_filter="ProcessUtilTest*:-ProcessUtilTest.GetAppOutput"

heap = 05670000, block = 0567e908

0:000> !heap
Index Address Name Debugging options enabled
1: 00160000
2: 00260000
3: 00270000
4: 00370000
5: 003a0000
6: 019b0000
7: 05670000
8: 02ff0000

it is used as a stack a couple of times:
thread initial stack: 0x05670000-0x0576e000-0x05770000, TOS=0x0576fffc
but not for any current thread

heap_tree does have the heap:
0:000> ?? *heap_tree->root->right->right
struct _rb_node_t
+0x000 parent : 0x18e3ea48
+0x004 right : 0x1a1db400
+0x008 left : 0x19e95424
+0x00c color : 1 ( BLACK )
+0x010 base : 0x05670000 "???"
+0x014 size : 0x100000
+0x018 max : (null)
+0x01c client : 0x1afaa3a4

so it's just missing the alloc

RtlpAllocateFromHeapLookaside does not call RtlAllocateHeap
instead it calls RtlpInterlockedPopEntrySList
but then RtlpActivateLowFragmentationHeap calls RtlFreeHeap w/ the result

also wondering about:
0:000> x ntdll!Rtl_Allocate_Heap*
7c96ceb9 ntdll!RtlDebugAllocateHeap =
7c919b80 ntdll!RtlReAllocateHeap =
7c9101d1 ntdll!RtlpAllocateFromHeapLookaside =
7c9100a4 ntdll!RtlAllocateHeap =
7c918f15 ntdll!RtlAllocateHeapSlowly =
7c96d24f ntdll!RtlDebugReAllocateHeap =
7c9601b0 ntdll!RtlpAllocateHeapUsageEntry =
7c9691e9 ntdll!RtlpDphShouldAllocateInPageHeap =

RtlDebugAllocateHeap calls RtlAllocateHeapSlowly
RtlAllocateHeapSlowly is long, doesn't seem to call RtlAllocateHeap...

p /x ((0x15+0x15*2)<<4) + 0x5670690
$6 = 0x5670a80

so could intercept and use the containing Heap of the arg
except need symbols:
% bin/winsyms.exe -e c:/windows/system32/ntdll.dll -s RtlpAllocateFromHeapLookaside
??

Original issue: http://code.google.com/p/drmemory/issues/detail?id=37

[derekbruening]

From timurrrr@google.com on October 27, 2010 07:20:44

Today we've moved our Chromium bots and the new DrM bot is Vista (AFAIK)
and it has started hitting this assert very often: http://build.chromium.org/p/chromium.fyi/builders/Windows%20Tests%20(DrMemory)/builds/130/steps/memory%20test:%20printing/logs/stdio ...
:::Dr.Memory::: ASSERT FAILURE (thread 3152): C:\drmemory-build\drmemory\common\alloc.c:2185: !pt->expect_lib_to_fail || pt->alloc_base == NULL (free() success unexpected)

Summary: ASSERT common/alloc.c:2185: !pt->expect_lib_to_fail || pt->alloc_base == NULL (free() success unexpected)
Labels: -Priority-Medium Priority-High

[derekbruening]

From timurrrr@google.com on October 27, 2010 07:41:14

(this is as of r64 / r436 since I couldn't build newer DrM yet)

btw, other tests on Vista hang silently - could be related
(see logs longer than 1200s http://build.chromium.org/p/chromium.fyi/builders/Windows%20Tests%20(DrMemory)/builds/130 )

[derekbruening]

From bruen...@google.com on February 11, 2011 12:58:07

I'm seeing this assert on any GUI app's exit on win7. looks like there it's an early alloc from the AV sw and the heap walk doesn't think it's legit.

[derekbruening]

From bruen...@google.com on February 14, 2011 16:30:31

the win7 exit-time assert is for different reason: issue #295 the one here is more closely related to issue #51 where the debug CRT should be disabled

[derekbruening]

From derek.br...@gmail.com on February 24, 2011 21:15:58

This issue was closed by revision r190 .

Status: Fixed