ASSERT (vs2012 /MD[d]: alloc_replace.c:3396: in_table (pre-us libc missed in heap walk)

[derekbruening]

From [email protected] on May 10, 2013 10:01:20

several win8 tests are now failing after the -replace_malloc update:

45: Dr.M ASSERT FAILURE (thread 2228):
45: C:\derek\drmemory\git\src\common\alloc_replace.c:3396: in_table (pre-us
45: libc missed in heap walk)<Core dump file for application

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

[derekbruening]

From [email protected] on May 10, 2013 07:50:29

the issue is that VS2012 (msvc110*.dll) uses ProcessHeap instead of its own heap

Summary: ASSERT (vs2012 /MD[d]: alloc_replace.c:3396: in_table (pre-us libc missed in heap walk) (was: ASSERT (win8 /MD[d]: alloc_replace.c:3396: in_table (pre-us libc missed in heap walk))

[derekbruening]

From [email protected] on May 10, 2013 08:20:24

This issue was closed by revision r1356 .

Status: Fixed

[derekbruening]

From [email protected] on May 12, 2013 21:28:21

re-opening for static libc:

*** TODO libc heap == ProcessHeap means static libc never calls RtlCreateHeap

shows up as invalid alloc ptr in wincrt, b/c the _get_heap_handle() heap
(=> ProcessHeap) doesn't map to the same arena as the malloc() call.

we create a separate arena at module walk time and never replace it.
thus we're using the wrong arena.

for shadow modes: could put watchpoint at !_crtheap.

could wait for 1st call to malloc and re-check !_crtheap?
should be safe to call _get_heap_handle at arbitrary points:

0:000> Uf wincrt!_get_heap_handle
wincrt!_get_heap_handle [f:\dd\vctools\crt_bld\self_x86\crt\src\heapinit.c @ 87]:
87 00931857 a124d39500 mov eax,[wincrt!_crtheap (0095d324)]
90 0093185c c3 ret

Status: Started

[derekbruening]

From [email protected] on May 14, 2013 09:03:12

This issue was closed by revision r1365 .

Status: Fixed