derekbruening
commented
9 years ago From bruen...@google.com on May 01, 2013 06:54:25
Another factor here is FP_SHOW_NON_MODULE_FRAMES: xref issue #145
Open derekbruening opened 9 years ago
derekbruening
commented
9 years ago From bruen...@google.com on May 01, 2013 06:54:25
Another factor here is FP_SHOW_NON_MODULE_FRAMES: xref issue #145
From bruen...@google.com on April 30, 2013 09:55:14
pasting from a user email:
Everything seems to work as expected except that memory access errors in stack frames (i.e. anything in the elf module) appear only one stack frame above the calling windows application.
E.g. I get a stack that looks like this:
0 (0x0511b11e) modid:0
1 loader.dll!runELF (0x102131d0 <loader.dll+0x2171d0>) modid:7
2 loader.dll!func5 (0x102131d0 <loader.dll+0x2131d0>) modid:7
3 loader.dll!func4 (0x101352f5 <loader.dll+0x1352f5>) modid:7
4 loader.dll!func3 (0x101355ef <loader.dll+0x1355ef>) modid:7
5 loader.dll!func2 (0x1013519b <loader.dll+0x13519b>) modid:7
6 loader.dll!func1 (0x100dbfb9 <loader.dll+0xdbfb9>) modid:7
7 KERNEL32.dll!BaseThreadInitThunk (0x76dc33aa <KERNEL32.dll+0x133aa>) modid:5
8 ntdll.dll!RtlInitializeExceptionChain (0x77be9ef2 <ntdll.dll+0x39ef2>) modid:6
9 ntdll.dll!RtlInitializeExceptionChain (0x77be9ec5 <ntdll.dll+0x39ec5>) modid:6
Where I would expect a stack that looks like:
0 (0x0511b11e) modid:0
1 (0x0511b0a0) modid:0
2 (0x0511b1ad) modid:0
3 loader.dll!runELF (0x102131d0 <loader.dll+0x2171d0>) modid:7
4 loader.dll!func5 (0x102131d0 <loader.dll+0x2131d0>) modid:7
5 loader.dll!func4 (0x101352f5 <loader.dll+0x1352f5>) modid:7
6 loader.dll!func3 (0x101355ef <loader.dll+0x1355ef>) modid:7
7 loader.dll!func2 (0x1013519b <loader.dll+0x13519b>) modid:7
8 loader.dll!func1 (0x100dbfb9 <loader.dll+0xdbfb9>) modid:7
9 KERNEL32.dll!BaseThreadInitThunk (0x76dc33aa <KERNEL32.dll+0x133aa>) modid:5
10 ntdll.dll!RtlInitializeExceptionChain (0x77be9ef2 <ntdll.dll+0x39ef2>) modid:6
11 ntdll.dll!RtlInitializeExceptionChain (0x77be9ec5 <ntdll.dll+0x39ec5>) modid:6
Additionally, the stack frame(s) disappear entirely when the ELF calls back into windows code, i.e. I get something like
0 loader.dll!func6 (0x102231d0 <loader.dll+0x2231d0>) modid:7
1 loader.dll!runELF (0x102131d0 <loader.dll+0x2171d0>) modid:7
2 loader.dll!func5 (0x102131d0 <loader.dll+0x2131d0>) modid:7
3 loader.dll!func4 (0x101352f5 <loader.dll+0x1352f5>) modid:7
4 loader.dll!func3 (0x101355ef <loader.dll+0x1355ef>) modid:7
5 loader.dll!func2 (0x1013519b <loader.dll+0x13519b>) modid:7
6 loader.dll!func1 (0x100dbfb9 <loader.dll+0xdbfb9>) modid:7
7 KERNEL32.dll!BaseThreadInitThunk (0x76dc33aa <KERNEL32.dll+0x133aa>) modid:5
8 ntdll.dll!RtlInitializeExceptionChain (0x77be9ef2 <ntdll.dll+0x39ef2>) modid:6
9 ntdll.dll!RtlInitializeExceptionChain (0x77be9ec5 <ntdll.dll+0x39ec5>) modid:6
where I would expect half a dozen frames between 0 & 1.
We should try to replace is_in_module() in is_retaddr() with a check for is_in_code_region() that includes DGC and non-PE mapped files.
Original issue: http://code.google.com/p/drmemory/issues/detail?id=1201