ASSERT: common\alloc.c:1197: is_entirely_in_heap_region(start, end) (heap data struct inconsistency) about drmemory HOT 31 CLOSED

From [email protected] on August 13, 2010 05:00:36

Smaller repro with source code:
(from Cygwin which is run from VS command prompt):
svn checkout http://data-race-test.googlecode.com/svn/trunk/ data-race-test
cd data-race-test/unittest
make
-> will produce data-race-test/unittest/bin/memory_unittest-windows-x86-O0.exe
drmemory.exe -- data-race-test\unittest\bin\memory_unittest-windows-x86-O0.exe
...
ASSERT ...(...): ...\common\alloc.c:1082: is_entirely_in_heap_region(start, end) (heap data struct inconsistency)

from drmemory.

From [email protected] on August 13, 2010 05:51:37

The attached binary shows "_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)" Abort/Retry/Ignore window under Dr.Memory (v1.2.1 downloaded from here) on Win XP 32-bit.
The binary is built using the steps described in comment #1 with all tests except "NonGtestTests.All" deleted from memory_unittests.cc

The binary passes if run natively or under r33 .

from drmemory.

From [email protected] on August 13, 2010 06:14:15

<attached again - last time it has failed for unknown reason>
Also added a couple of debug-printfs.
The first "AAA" printf is located at the beginning of main().

Attachment: memory_unittest.zip

from drmemory.

From [email protected] on August 13, 2010 07:35:27

A similar crash is reproducible on a simlple googletest unittest, see issue #26 .

Probably, it's worth fixing issue #26 as a first step.

Labels: -Priority-Critical Priority-High

from drmemory.

From [email protected] on August 23, 2010 05:49:33

This has gone away with the issue #26 fix.
Thank you!

Status: Duplicate
Mergedinto: 26

from drmemory.

From [email protected] on August 23, 2010 06:23:11

Sorry, my mistake - the assert is still present on the old base_unittests binary (from dr issue #251 )

Status: Accepted
Mergedinto: -26

from drmemory.

From [email protected] on August 23, 2010 08:12:18

I've been running the issue #251 binary on XPSP2 and have not seen this. Per your initial comment this happens right up front?

can you run with "-verbose 2 -pause_at_assert", attach windbg at the assert, point it at the symbols (since drmemorylib.dll isn't on the loader list), get the address of the malloc in question, and then look in the logfile for "adding heap region" and "removing heap region" entries and figure out where the malloc sits in relation to the heap regions known to DrMem?

to set symbols in windbg:
.sympath c:\my\drmemory\dir\bin\debug
.reload drmemory.dll=10000000

from drmemory.

From [email protected] on August 23, 2010 08:56:33

Now it passes the initial phase but then fails inside tests (example: MessageLoopTest.RecursiveDenial1)

For the record, my XP is SP3.

I'll try these flags and windbg now.

Summary: ASSERT: common\alloc.c:1197: is_entirely_in_heap_region(start, end) (heap data struct inconsistency)

from drmemory.

From [email protected] on August 23, 2010 10:11:16

I'm not familiar with windbg yet, so I've just patched the sources locally to print 'start' and 'end':
(also I've removed "??:0" lines from the output)

inside heap routine: adding nop-if-mem-unaddr checks
in event_basic_block(tag=0x5ad8bf83)
inside heap routine: adding nop-if-mem-unaddr checks
exiting heap routine: NOT adding nop-if-mem-unaddr checks
leaving alloc routine 0x77c2c407 malloc
malloc-post 0x00f717f8-0x00f71878 = 0x80 (really 0x00f717f0-0x00f71888 0x98)
malloc-post changing from 0x00f717f0 to 0x00f717f8
@@@ unique callstack #10920
WARNING: unable to load symbols for C:\Windows\system32\uxtheme.dll
0x5ad8bf83 <UxTheme.dll+0x1bf83> UxTheme.dll!GetThemeTextMetrics
0x5ad7165e <UxTheme.dll+0x165e> UxTheme.dll!?
0x7c90118a <ntdll.dll+0x118a> ntdll.dll!LdrInitializeThunk
0x7c91c4fa <ntdll.dll+0x1c4fa> ntdll.dll!LdrFindResourceDirectory_U
0x7c916371 <ntdll.dll+0x16371> ntdll.dll!RtlValidateUnicodeString
0x7c9164d3 <ntdll.dll+0x164d3> ntdll.dll!LdrLoadDll
0x7c801bbd <KERNEL32.dll+0x1bbd> KERNEL32.dll!LoadLibraryExW
0x7e428055 <USER32.dll+0x18055> USER32.dll!GetGUIThreadInfo
0x7c90e473 <ntdll.dll+0xe473> ntdll.dll!KiUserCallbackDispatcher
0x7e42e442 <USER32.dll+0x1e442> USER32.dll!GetScrollInfo
0x7e42d0d6 <USER32.dll+0x1d0d6> USER32.dll!CreateWindowExW
0x007361aa <base_unittests.exe+0x3361aa> base_unittests.exe!base::MessagePumpForUI::InitMessageWnd
c:\users\timurrrr\desktop\chromium\src\base\message_pump_win.cc:249
...
is_entirely_in_heap_region(start=0x00f717f8, end=0x00f71878) failed!

from drmemory.

From [email protected] on August 23, 2010 10:14:23

$ grep "heap region" <global.log>
adding heap region 0x00160000-0x00260000 arena
adding heap region 0x00160000-0x00260000
set heap region 0x00160000-0x00260000 Heap to 0x00160000
adding heap region 0x00260000-0x00270000 arena
adding heap region 0x00260000-0x00270000
set heap region 0x00260000-0x00270000 Heap to 0x00260000
adding heap region 0x00270000-0x00280000 arena
adding heap region 0x00270000-0x00280000
set heap region 0x00270000-0x00280000 Heap to 0x00270000
adding heap region 0x00350000-0x00360000 arena
adding heap region 0x00350000-0x00360000
set heap region 0x00350000-0x00360000 Heap to 0x00350000
adding heap region 0x00380000-0x00390000 arena
adding heap region 0x00380000-0x00390000
set heap region 0x00380000-0x00390000 Heap to 0x00380000
adding heap region 0x003e0000-0x003f0000 arena
adding heap region 0x003e0000-0x003f0000
set heap region 0x003e0000-0x003f0000 Heap to 0x003e0000
adding heap region 0x011f0000-0x01200000 arena
adding heap region 0x011f0000-0x01200000
set heap region 0x011f0000-0x01200000 Heap to 0x011f0000
adding heap region 0x01220000-0x01230000 arena
adding heap region 0x01220000-0x01230000
set heap region 0x01220000-0x01230000 Heap to 0x01220000
adding heap region 0x01500000-0x01600000 arena
adding heap region 0x01500000-0x01600000
set heap region 0x01500000-0x01600000 Heap to 0x01500000
adding heap region 0x01f00000-0x01f10000 arena
adding heap region 0x01f00000-0x01f10000
set heap region 0x01f00000-0x01f10000 Heap to 0x01f00000
adding heap region 0x02ee0000-0x02fe0000 arena
adding heap region 0x02ee0000-0x02fe0000

from drmemory.

From [email protected] on August 23, 2010 10:29:05

can you attach the global.*.log (compress it to save space)

from drmemory.

From [email protected] on August 23, 2010 11:36:04

Sure.

Attachment: 23.zip

from drmemory.

From [email protected] on August 23, 2010 13:59:45

intercepting malloc @0x77c2c407 size_func=0x77c2bf6c in module msvcrt.dll

grep 0x00f global.6868.log
initial unknown committed region 0x00f70000-0x00f78000
set range 0x00f70000-0x00f78000 => 0x0
replacing shadow special 0x25dc0200 block for write @0x00f70000 0
malloc-post 0x00f717f8-0x00f71878 = 0x80 (really 0x00f717f0-0x00f71888 0x98)
malloc-post changing from 0x00f717f0 to 0x00f717f8
start=0x00f717f8, end=0x00f71878

grep -E '^entering|^leaving|^ASSERT' global.6868.log | tail
entering alloc routine 0x7c9100c4 RtlAllocateHeap direct pre-retaddr
leaving alloc routine 0x7c9100c4 RtlAllocateHeap
entering alloc routine 0x7c90ff2d RtlFreeHeap direct pre-retaddr
leaving alloc routine 0x7c90ff2d RtlFreeHeap
entering alloc routine 0x7c9100c4 RtlAllocateHeap direct pre-retaddr
leaving alloc routine 0x7c9100c4 RtlAllocateHeap
entering alloc routine 0x77c2c407 malloc indirect pre-retaddr
entering heap routine: adding nop-if-mem-unaddr checks
leaving alloc routine 0x77c2c407 malloc
ASSERT FAILURE (thread 7600): Z:\drmemory\GIT_SVN\common\alloc.c:1200: should_be_true (heap data struct inconsistency)

grep '^walking heap' global.6868.log
walking heap 0 0x00160000
walking heap 1 0x00260000
walking heap 2 0x00270000
walking heap 3 0x00350000
walking heap 4 0x00380000
walking heap 5 0x003e0000
walking heap 6 0x011f0000
walking heap 7 0x01220000
walking heap 8 0x01500000

grep '^initial unk' global.6868.log
initial unknown committed region 0x00150000-0x00151000
initial unknown committed region 0x00360000-0x00361000
initial unknown committed region 0x00370000-0x00371000
initial unknown committed region 0x00f70000-0x00f78000
initial unknown committed region 0x01170000-0x01171000
initial unknown committed region 0x01260000-0x01261000
initial unknown committed region 0x01270000-0x01271000
initial unknown committed region 0x01280000-0x01281000
initial unknown committed region 0x01290000-0x01291000
initial unknown committed region 0x012a0000-0x012a1000
initial unknown committed region 0x01600000-0x01700000
initial unknown committed region 0x01700000-0x01900000
initial unknown committed region 0x01900000-0x01987000
initial unknown committed region 0x01990000-0x01a10000
initial unknown committed region 0x01a20000-0x01b49000
initial unknown committed region 0x01b4a000-0x01b51000
initial unknown committed region 0x01b52000-0x01b8c000
initial unknown committed region 0x01b8d000-0x01e20000
initial unknown committed region 0x01e20000-0x01ef8000
initial unknown committed region 0x01f10000-0x02010000
initial unknown committed region 0x02010000-0x02092000
initial unknown committed region 0x020a0000-0x026e0000
initial unknown committed region 0x026e0000-0x02ee0000
initial unknown committed region 0x03120000-0x03287000
initial unknown committed region 0x03288000-0x03302000
initial unknown committed region 0x03305000-0x0330b000
initial unknown committed region 0x04120000-0x04306000
initial unknown committed region 0x04320000-0x043b4000
initial unknown committed region 0x04650000-0x0482a000
initial unknown committed region 0x04830000-0x04b2e000
initial unknown committed region 0x04b30000-0x04efb000
initial unknown committed region 0x04f30000-0x0506e000

PROBLEMS:

1. what are all these unknown regions: and how many are heaps?
   they didn't show up in the Rtl heap iteration.
   w/ early injection what would their allocs look like?
   w/o early injection how can drmem find them?
2. this malloc came straight from msvcrt w/ no call to Rtl...have we seen
   that before (other than cygwin)?
   the call is a plain libc malloc call. what makes it decide to use its
   private heap rather than call into Rtl?

from drmemory.

From [email protected] on August 24, 2010 05:35:13

(How) Can I provide some additional info/logs?

from drmemory.

From [email protected] on August 24, 2010 08:41:45

my testing has all been on 64-bit XPSP2. let me find a 32-bit XPSP3 (I assume yours is 32-bit? there is no 64-bit XPSP3 I don't think) and try to repro. this is big enough I would like to have it in front of me.

from drmemory.

From [email protected] on August 24, 2010 13:02:11

Yes, my XP SP3 is 32-bit running inside VMware player.
Looking forward for the results!

from drmemory.

From [email protected] on August 25, 2010 22:00:35

I still can't reproduce the assert. I have an XPSP3 VM (Version 5.1.2600 Service Pack 3 Build 2600). When I run the full test list I hit this assert which I will file separately:

[----------] 4 tests from WMIUtilTest
[ RUN ] WMIUtilTest.TestLocalConnectionSecurityBlanket
:::Dr.Memory::: ASSERT FAILURE (thread 134248): E:/derek/dr/win32/oss-clients/drmemory/drmemory/readwrite.c:2564: addr + sz > addr (address overflow)

After fixing that, the full test list aborts at:
Now ends with:
[----------] 3 tests from FileVersionInfoTest
[ RUN ] FileVersionInfoTest.HardCodedProperties
Assertion failed: ptr_ != NULL, file c:\Users\timurrrr\Desktop\chromium\src\base/scoped_ptr.h, line 93
Is "--gtest_catch_exceptions" how you continue beyond asserts?)

If I explicitly run MessageLoopTest*, they all succeed

from drmemory.

From [email protected] on August 26, 2010 02:54:13

Can you please publish the fix for WMIUtilTest.TestLocalConnectionSecurityBlanket ?

You can skip FileVersion tests by using --gtest_filter="-FileVersion*" as they fail when run natively as well

from drmemory.

From [email protected] on August 26, 2010 03:24:07

On my machine, the base_unittests from dr issue #251 pass WITHOUT Dr.Memory with
--gtest_filter="-FileVersion*:ProcessUtilTest.GetAppOutput:ReadOnlyFileUtilTest.ContentsEqual:ReadOnlyFileUtilTest.TextContentsEqual:DataPackTest.Load"

from drmemory.

From [email protected] on August 26, 2010 07:58:17

I still can't reproduce the assert.
Could this because of AV software installed on my machine?
I think I've disabled it but you know you can't be 100% sure on Windows :)

from drmemory.

From [email protected] on August 26, 2010 18:07:37

Can you please publish the fix for WMIUtilTest.TestLocalConnectionSecurityBlanket ?

Still working on generalizing it since I hit it in another form. Filed as issue #35 .
Are you seeing it too?

Could this because of AV software installed on my machine?
I think I've disabled it but you know you can't be 100% sure on Windows :)

It is present:
module load event: "sophos_detoured.dll" 0x6fa00000-0x6fa3e000

First let's see whether our msvcrt.dll versions are different.

Here's mine, from windbg:
0:001> lm vm msvcrt
start end module name
77c10000 77c68000 msvcrt (deferred)
Image path: C:\WINDOWS\system32\msvcrt.dll
Image name: msvcrt.dll
Timestamp: Sun Apr 13 17:12:56 2008 (4802A188)
CheckSum: 00057341
ImageSize: 00058000
File version: 7.0.2600.5512
Product version: 6.1.8638.5512
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: msvcrt.dll
OriginalFilename: msvcrt.dll
ProductVersion: 7.0.2600.5512
FileVersion: 7.0.2600.5512 (xpsp.080413-2111)
FileDescription: Windows NT CRT DLL
LegalCopyright: © Microsoft Corporation. All rights reserved.

What version do you have?

from drmemory.

From [email protected] on August 27, 2010 03:16:55

I got exactly the same results for "lm vm msvcrt".

from drmemory.

From [email protected] on August 27, 2010 05:32:20

I've reproduced the original assert on the Chromium bot (without AV) on media tests:

$ drmemory.exe media_unittests --gtest_filter="*NoStreams"
...
[==========] Running 2 tests from 2 test cases.
[----------] Global test environment set-up.
[----------] 1 test from PipelineImplTest
[ RUN ] PipelineImplTest.NoStreams
05:27:49 common.py [INFO] process ended, did not time out
...
05:27:49 common.py [ERROR] C:\b\slave\chromium-dbg-win-drmemory\build\src\tools\valgrind....\third_party\drmemory\unpacked\exports32\bin\drmemory.exe exited with non-zero result code -1
...
05:27:49 drmemory_analyze.py [ERROR]
ASSERT FAILURE (thread 5064): C:\DELETEME\drmemory\common\alloc.c:1197: is_entirely_in_heap_region(start, end) (heap data struct inconsistency)

The media_unittests binary takes 13Mb in .zip so I'll send it to you via e-mail

from drmemory.

From [email protected] on August 29, 2010 12:03:30

hmmm it works for me, with or without icudt42.dll in the dir:

C:\derek\media\build\Debug>c:\derek\DrMemory-Windows-1.2.1-1\bin\drmemory.exe -pause_at_assert -- media_unittests.exe --gtest_filter="*NoStreams"
:::Dr.Memory::: Dr. Memory version 1.2.2
:::Dr.Memory::: options are "-pause_at_assert -logdir c:\derek\DrMemory-Windows-1.2.1-1/drmemory/logs -resfile_out "
:::Dr.Memory::: log dir is c:\derek\DrMemory-Windows-1.2.1-1/drmemory/logs/DrMemory-media_unittests.exe.131504.000
Note: Google Test filter = *NoStreams
[==========] Running 2 tests from 2 test cases.
[----------] Global test environment set-up.
[----------] 1 test from PipelineImplTest
[ RUN ] PipelineImplTest.NoStreams
[ OK ] PipelineImplTest.NoStreams (4344 ms)
[----------] 1 test from PipelineImplTest (4375 ms total)

[----------] 1 test from FFmpegDemuxerTest
[ RUN ] FFmpegDemuxerTest.Initialize_NoStreams
[ OK ] FFmpegDemuxerTest.Initialize_NoStreams (3578 ms)
[----------] 1 test from FFmpegDemuxerTest (3578 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 2 test cases ran. (8250 ms total)
[ PASSED ] 2 tests.

YOU HAVE 1 DISABLED TEST

:::Dr.Memory::: ERRORS FOUND:
:::Dr.Memory::: 0 unique, 0 total unaddressable access(es)
:::Dr.Memory::: 96 unique, 644 total uninitialized access(es)
:::Dr.Memory::: 0 unique, 0 total invalid heap argument(s)
:::Dr.Memory::: 0 unique, 0 total warning(s)
:::Dr.Memory::: 1 total, 748 byte(s) of leak(s)
:::Dr.Memory::: (re-run with "-check_leaks" for details)
:::Dr.Memory::: 0 total, 0 byte(s) of possible leak(s)
:::Dr.Memory::: (re-run with "-check_leaks -possible_leaks" for details)
:::Dr.Memory::: ERRORS IGNORED:
:::Dr.Memory::: 0 suppressed error(s)
:::Dr.Memory::: 0 suppressed leak(s)
:::Dr.Memory::: 338 ignored assumed-innocuous system leak(s)
:::Dr.Memory::: 267 still-reachable allocation(s)
:::Dr.Memory::: (re-run with "-check_leaks -show_reachable" for details)
:::Dr.Memory::: 0 error(s) beyond -report_max
:::Dr.Memory::: 0 leak(s) beyond -report_leak_max
:::Dr.Memory::: Details: c:\derek\DrMemory-Windows-1.2.1-1/drmemory/logs/DrMemory-media_unittests.exe.131504.000/results.txt

from drmemory.

From [email protected] on August 30, 2010 04:07:00

Does it pass without --gtest_filter?

Here's a list of test I've seen failing under Dr.Memory http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/valgrind/media_unittests.gtest-drmemory_win32.txt?revision=57679&view=markup

from drmemory.

From [email protected] on October 06, 2010 05:21:01

r65 fails on memory_unittests.exe with this assert when run with
drmemory.exe -- memory_unittest-windows-x86-O0.exe --gtest_filter="EmptyThread"

Can you please try it locally?

Attachment: memory_unittest.zip

from drmemory.

From [email protected] on October 06, 2010 05:42:04

Also, the code from issue #18 fails with this assertion as of r65

from drmemory.

From [email protected] on October 10, 2010 22:33:57

grrr, I still can't repro: I tried the issue #18 app and the attached memory_unittest-windows-x86-O0.exe on both xp64sp2 and xp32sp3. I used a couple different versions of drmemory.

from drmemory.

From [email protected] on January 18, 2011 04:36:56

I can repro it with the code snippet from issue #12 .
Don't forget to create a test.txt file besides the test.c and test.exe

from drmemory.

From [email protected] on February 16, 2011 15:30:33

taking another look: it's priv lib allocs that are changing app heap!

I can repro this assert with:
/usr/bin/time ~/drmemory/git/build_drmemory/bin/drmemory.exe -dr c:/src/dr/git/exports -- ./base_unittests.exe --gtest_filter="TimeTicks_" :::Dr.Memory::: Dr. Memory version 1.3.174
:::Dr.Memory::: options are "-logdir C:\src\drmemory\git\build_drmemory/logs -resfile_out "
:::Dr.Memory::: log dir is C:\src\drmemory\git\build_drmemory/logs/DrMemory-base_unittests.exe.71564.000
Note: Google Test filter = TimeTicks_
[==========] Running 8 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 8 tests from TimeTicks
[ RUN ] TimeTicks.WinRollover
:::Dr.Memory::: ASSERT FAILURE (thread 69244): ..\src\common\alloc.c:1608: is_entirely_in_heap_region(start, end) (heap data struct inconsistency)

turns out the missing heap region was created by dbghelp.dll invoking
kernel32 operator new which calls kernel32 malloc which calls HeapAlloc on
kernel32!_crtheap. => need to intercept RtlCreateHeap and all heap allocs
on such heaps.
=> part of DRi#235: redirect more of ntdll

simplifying RtlDestroyHeap handling: leaving interior-freeing to issue #385

note that TimeTicks.WinRollover creates 32K threads and is extremely slow under
debug drmemory + debug DR:
[ OK ] TimeTicks.WinRollover (1787355 ms)
both release we have:
[ OK ] TimeTicks.WinRollover (56995 ms)
later run w/ both debug but DR loglevel 0, so was it really loglevel 1
that was so slow?!?
[ OK ] TimeTicks.WinRollover (143069 ms)

my initial redirections are not enough: allocations from ntdll are not redirected => need priv default heap

this one is using the process heap:
0:004> kb
ChildEBP RetAddr Args to Child
24e39b50 6f88698c 50000018 00000004 00000003 ntdll!NtRaiseHardError+0x12
24e39ba0 6f8571f4 6f97c258 6f9698f8 00000000 dynamorio!nt_messagebox+0xec [c:\src\dr\git\src\core\win32\ntdll.c @ 3251]
24e39bb4 6f720b78 24e39bc8 00000000 00000000 dynamorio!debugbox+0x54 [c:\src\dr\git\src\core\win32\os.c @ 3418]
24e39ed0 6f8612c6 00000004 00000001 00000001 dynamorio!notify+0x1d8 [c:\src\dr\git\src\core\utils.c @ 1852]
24e39f38 203c3164 24e39f44 0000000c 203c328f dynamorio!syscall_while_native+0x546 [c:\src\dr\git\src\core\win32\syscall.c @ 482]
WARNING: Frame IP not in any known module. Following frames may be wrong.
03e9f7d8 77d5b762 0042f000 03e9f7f4 003f0000 0x203c3164
03e9f800 77d5b6cd 003f0000 00000210 6058daf1 ntdll!RtlpExtendHeap+0x2a
03e9f8e0 77d53070 00000208 00000210 003f00c4 ntdll!RtlpAllocateHeap+0x7e0
03e9f964 77d59a20 003f0000 002c0008 00000208 ntdll!RtlAllocateHeap+0x23a
03e9f988 002c2e83 00000000 00000000 20aede20 ntdll!RtlProcessFlsData+0xb9
03e9f99c 00bda4f2 00000004 20aede20 24d14068 KERNELBASE_2b0000!FlsSetValue+0x2a
03e9f9b4 00bda48c 00000000 03e9f9e4 6f8a9c37 msvcrt_bd0000!_core_crt_dll_init+0x244
03e9f9c0 6f8a9c37 00bd0000 00000002 00000000 msvcrt_bd0000!_CRTDLL_INIT+0x1b
03e9f9e4 6f7d1506 202d43f4 00000002 202d43f4 dynamorio!privload_call_entry+0xe7 [c:\src\dr\git\src\core\win32\loader.c @ 959]
03e9f9f8 6f6a27e2 24d13fc0 00000000 00000000 dynamorio!loader_thread_init+0x76 [c:\src\dr\git\src\core\loader_shared.c @ 189]
03e9fa44 6f87c0b5 00000000 03e9fb14 00000000 dynamorio!dynamo_thread_init+0x622 [c:\src\dr\git\src\core\dynamo.c @ 2108]
03e9fbc4 6f87bdbf 03e9fcb0 00000000 03e9fcb0 dynamorio!intercept_new_thread+0x125 [c:\src\dr\git\src\core\win32\callback.c @ 2594]
03e9fbd8 203c1091 03e9fbe4 00000000 203c10e0 dynamorio!intercept_ldr_init+0x6f [c:\src\dr\git\src\core\win32\callback.c @ 2844]

should at least have a different default heap: set private_peb->ProcessHeap.

with that in place, at exit hitting what I suspect is the free of something
that was allocated on the app's default heap:

178f901c 17951381 178f9028 00000000 179513f7 dynamorio!intercept_exception+0x730 [c:\src\dr\git\src\core\win32\callback.c @ 4715]
WARNING: Frame IP not in any known module. Following frames may be wrong.
178f944c 77d52d07 02bd0000 004deed8 178f9514 0x17951381
178f9544 77d52bf2 004deed8 004deee0 004deee0 ntdll!RtlpFreeHeap+0x1f4
178f9564 77d842a0 02bd0000 00000000 004deee0 ntdll!RtlFreeHeap+0x142
178f957c 77d7eb41 004deee0 02a736d7 0000ae5b ntdll!RtlpFreeTebLanguageList+0x3a
178f9584 02a736d7 0000ae5b 00000001 178fa000 ntdll!RtlCleanUpTEBLangLists+0x2f
178f99d0 02959c67 02a60000 00000003 00000000 kernel32_2a60000!_BaseDllInitialize+0x67
178f99f4 02881577 17863e24 00000003 17863e24 dynamorio!privload_call_entry+0xe7 [c:\src\dr\git\src\core\win32\loader.c @ 974]
178f9a08 02750d01 17897900 02752910 17897900 dynamorio!loader_thread_exit+0x47 [c:\src\dr\git\src\core\loader_shared.c @ 208]
178f9a20 02751128 00000000 00000000 17897900 dynamorio!dynamo_shared_exit+0x1d1 [c:\src\dr\git\src\core\dynamo.c @ 945]
178f9a34 02751068 178f9a4c 026f112d 026f11ac dynamorio!dynamo_process_exit_cleanup+0xb8 [c:\src\dr\git\src\core\dynamo.c @ 1199]
178f9a3c 026f112d 026f11ac 178fa000 029176d9 dynamorio!dynamo_process_exit+0xb8 [c:\src\dr\git\src\core\dynamo.c @ 1258]
178f9a4c 17897900 00000029 0015fbbc 0015fbbc dynamorio!cleanup_and_terminate+0x4a

0:000> ?? private_peb->ProcessHeap
void * 0x02bd0000

=> turning private RtlCleanUpTEBLangLists into nop makes it all work

from drmemory.

From [email protected] on February 16, 2011 16:29:52

This issue was closed by revision r178 .

Status: Fixed

from drmemory.