From bruen...@google.com on November 29, 2011 09:03:06

works fine with -no_follow_children

From bruen...@google.com on November 29, 2011 11:51:37

also works with -dr_ops "-no_early_inject"

fails even with -dr_ops "-no_private_peb -no_private_loader -stderr_mask 15" -no_replace_libc -no_replace_realloc -no_repstr_to_loop -no_use_symcache -perturb_only

works with plain DR and bbcount client

curiouser and curiouser. something happens while loading app's kernel32.dll that causes it to freak out and it aborts.

From bruen...@google.com on November 29, 2011 13:52:56

it looks like any child process on xp32 is going to die very early under drmem. this seems to come from the private copy of kernel32.dll being loaded before the app's copy. may have implications for earliest injection: though other platforms seem to handle this just fine. TODO: check 2K: could be a partition point at XP/2003.

so this can explain any number of test failures on xp32

base_unittests.exe ProcessUtilTest.SpawnChild seems to work fine.
ProcessUtilTest.SpawnChild does indeed pass, however, the child crashes
very early in the same manner as ipc test :)
so the test just isn't complete enough to figure that out

***** TODO add crtprcs test to drmem suite

From timurrrr@google.com on November 30, 2011 01:26:19

so the test just isn't complete enough to figure that out
Should we file a bug or fix it?

From timurrrr@google.com on December 02, 2011 00:41:36

temporary work-around commited in r644

From bruen...@google.com on July 09, 2012 16:14:40

** TODO now this happens on vista+ wow64

the procterm test started failing after DR r1427 made from-parent injection
early on vista+ wow64 (for separately-built DR: drmem's copy of DR has not
yet been updated but will be soon)

drmemory-dbg-32: 43 tests passed, **** 2 tests failed, of which 1 were flaky: ****
realloc_FLAKY
procterm => CURIOSITY : reached_image_entry_yet() || ( (((void)(((dynamo_options.checklevel = (1)) !(!((OPTION_IS_STRING_thin_client)) || (((options_lock)-num_readers 0) || self_owns_write_lock(options_lock)))) ? (internal_error(D:\derek\dr\git\src\core\win32\os.c,; CURIOSITY : reached_image_entry_yet() || (

after adding a timeout (!):
waiting for file
waiting for file
waiting for file
terminating child
child has exited with status -1073741800
app exiting

(gdb) p /x -1073741800
$1 = 0xc0000018
#define STATUS_CONFLICTING_ADDRESSES ((NTSTATUS)0xC0000018L)

running w/ drmem verbosity:

drmem takes over before kernel32.dll is loaded. its load hits:

mmap file 0x00b70000-0x00c80000
processing post system call #0x25 NtMapViewOfSection res=0x40000003
#define STATUS_IMAGE_NOT_AT_BASE ((NTSTATUS)0x40000003L)

module load event: "drmemorylib.dll" 0x73800000-0x73ca6000 modid: 3 D:\derek\drmemory\git\build_x86_dbg/bin/debug/drmemorylib.dll

module load event: "KERNEL32.dll" 0x00b70000-0x00c80000 modid: 5 C:\Windows\SysWOW64\kernel32.dll

gets unmapped:
system call #0x27 NtUnmapViewOfSection

0 ntdll.dll!LdrpFindOrMapDll+0x4c30 (0x77190d3d <ntdll.dll+0x40d3d>) modid:0

1 fp=0x00b6f36c parent=0x00b6f4ec ntdll.dll!LdrpLoadDll+0x1aa (0x7718c3a9 <ntdll.dll+0x3c3a9>) modid:0

2 fp=0x00b6f4ec parent=0x00b6f524 ntdll.dll!LdrLoadDll+0x7a (0x7718c4d5 <ntdll.dll+0x3c4d5>) modid:0

3 fp=0x00b6f524 parent=0x00b6f6b0 ntdll.dll!LdrpInitializeProcess+0xfffff6a3 (0x77196625 <ntdll.dll+0x46625>) modid:0

4 fp=0x00b6f6b0 parent=0x00b6f700 ntdll.dll!_LdrpInitialize+0xb4f8 (0x771952d6 <ntdll.dll+0x452d6>) modid:0

5 fp=0x00b6f700 parent=0x00b6f710 ntdll.dll!LdrInitializeThunk+0xf (0x77189e79 <ntdll.dll+0x39e79>) modid:0

6 fp=0x00b6f710 parent=0x00000000 arg 0 = 0xffffffff

% dumpbin /headers c:/windows/syswow64/kernel32.dll | grep 'image base'
7DD60000 image base (7DD60000 to 7DE6FFFF)

DR dll base = 0x62820000
% grep ': loaded' ~/dr/git/exports/logs/procterm.exe.9416.00000000/procterm.exe.0.7128.html
privload_load_finalize: loaded KERNELBASE.dll @ 0x766a0000-0x766e6000 from C:\Windows/system32/KERNELBASE.dll
privload_load_finalize: loaded KERNEL32.dll @ 0x766f0000-0x76800000 from C:\Windows/system32/KERNEL32.dll
privload_load_finalize: loaded msvcrt.dll @ 0x75110000-0x751bc000 from C:\Windows/system32/msvcrt.dll
privload_load_finalize: loaded dbghelp.dll @ 0x67020000-0x67140000 from D:\derek\drmemory\git\build_x86_dbg/bin/debug/dbghelp.dll
privload_load_finalize: loaded drmemorylib.dll @ 0x73800000-0x73ca6000 from D:\derek\drmemory\git\build_x86_dbg/bin/debug/drmemorylib.dll

so doesn't seem to be a conflict in address space, but probably a csrss or
other global registration that the private kernel32 already did and which
is translated back to this status code?