Re: Callstack for <not in module> frames appears rolled up.

[Derek Bruening]

Our callstack walker looks for return addresses in modules.  The simplest experiment is to try removing the is_in_module() check from is_retaddr() in common/callstack.c.

On Tue, Apr 30, 2013 at 9:09 AM, Simon Gates <simon...@semi-evolved.com> wrote:

Hi,

I'm trying to use Dr Memory to detect leaks & access violations on windows, but in non windows code.

I have a standard windows executable that loads and runs x86 code in ELF (+ DWARF3) format. The ELF code also calls back into windows DLLs.

Everything seems to work as expected except that memory access errors in <not in module> 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 <not in a module> (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 <not in a module> (0x0511b11e) modid:0

# 1 <not in a module> (0x0511b0a0) modid:0

# 2 <not in a module> (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 <not in a module> 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.

I understand that Dr Memory doesn't currently support ELF/DWARF on windows - I'm intending to add the stack info myself - and I'm currently using the command line args:

 "-log_suppressed_errors -show_all_threads -no_callstack_use_top_fp -callstack_style 0xf"

Is there anything I can add that will keep the frames, or alternately, I'm happy to modify the code to fix this so can anyone point me to where this is happening?

Thanks,

Simon.

--
 
---
You received this message because you are subscribed to the Google Groups "Dr. Memory Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Simon Gates]

On Tuesday, 30 April 2013 14:43:55 UTC+1, Derek Bruening wrote:

Our callstack walker looks for return addresses in modules.  The simplest experiment is to try removing the is_in_module() check from is_retaddr() in common/callstack.c.

Thanks, I give that a go.

Simon. 

[Simon Gates]

On Tuesday, 30 April 2013 14:43:55 UTC+1, Derek Bruening wrote:

Our callstack walker looks for return addresses in modules.  The simplest experiment is to try removing the is_in_module() check from is_retaddr() in common/callstack.c.

Unfortunately, that doesn't seem to make any difference. I'll have a look tomorrow, add some tracing and see what's happening.

Thanks.

Simon.

[Simon Gates]

On Tuesday, 30 April 2013 14:43:55 UTC+1, Derek Bruening wrote:

Our callstack walker looks for return addresses in modules.  The simplest experiment is to try removing the is_in_module() check from is_retaddr() in common/callstack.c.

HI, 

I get the call stack I need if, as well as removing the is_in_module() check you suggest, I add the FP_SHOW_NON_MODULE_FRAMES flag to the call to callstack_init(...) in drmemory/report.c

There's a comment in the code about exposing the flags here, which I'd vote for :-) although I'd guess is_in_module() would have to become a more general check for executable memory at the same time.

Thanks,

Simon.

[Derek Bruening]

Issue 1201 is tracking this.

Thanks,

Simon.

--