Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

compiling with asan generates wrong DWARF #235

Closed
ramosian-glider opened this issue Aug 31, 2015 · 18 comments
Closed

compiling with asan generates wrong DWARF #235

ramosian-glider opened this issue Aug 31, 2015 · 18 comments
Labels
Priority-High ProjectAddressSanitizer Status-Fixed Type-Defect

Comments

@ramosian-glider
Copy link
Member

Originally reported on Google Code with ID 235

What steps will reproduce the problem?
1. Compile the attached file with:
clang -fsanitize=address asan.cc -g -o hello -O0
2. Inspect the dwarf, looking at the locals of main() argc and argv

What is the expected output? What do you see instead?
It turns out that the DWARF is emitting location info for the locals:
0x0000005f:     TAG_subprogram [5] *
                 AT_name( "main" )
                 AT_decl_file( "/private/tmp/asan/src.cc" )
                 AT_decl_line( 5 )
                 AT_type( {0x00000058} ( int ) )
                 AT_external( 0x01 )
                 AT_low_pc( 0x0000000100000b90 )
                 AT_high_pc( 0x0000000100000e87 )
                 AT_frame_base( rbp )

0x0000007d:         TAG_formal_parameter [3]  
                     AT_name( "argc" )
                     AT_decl_file( "/private/tmp/asan/src.cc" )
                     AT_decl_line( 5 )
                     AT_type( {0x00000058} ( int ) )
                     AT_location( 0x00000038
                        0x0000000100000b90 - 0x0000000100000ca4: rdi
                        0x0000000100000ca4 - 0x0000000100000cbe: rsp+48, deref )

0x0000008c:         TAG_formal_parameter [3]  
                     AT_name( "argv" )
                     AT_decl_file( "/private/tmp/asan/src.cc" )
                     AT_decl_line( 5 )
                     AT_type( {0x000000a8} ( char** ) )
                     AT_location( 0x00000070
                        0x0000000100000b90 - 0x0000000100000ca9: r8
                        0x0000000100000ca9 - 0x0000000100000cbe: rsp+40, deref )

but the ranges are too small to cover the entire function space, e.g. for "argv"

                     AT_location( 0x00000070
                        0x0000000100000b90 - 0x0000000100000ca9: r8
                        0x0000000100000ca9 - 0x0000000100000cbe: rsp+40, deref )

So when debugging in LLDB, we stop at 
(lldb) reg read pc
     rip = 0x0000000100000d84  hello`main + 500 at asan.cc:6
and the function PC space is:
                 AT_low_pc( 0x0000000100000b90 )
                 AT_high_pc( 0x0000000100000e87 )
but while we are validly inside main(), the DWARF fails to vend a location for the,
existing and available, locals
If one manually follows the directions given by DWARF:
                        0x0000000100000ca4 - 0x0000000100000cbe: rsp+48, deref )
(lldb) expr *((int*)$rsp+48)
(int) $5 = 4 <— this is assuming one launches the inferior in LLDB with, say, "run
1 2 3"

the right value comes out

It looks like it might simply be a matter of extending the location to cover the whole
address space

This reproduces for me on OS X with ToT clang/asan

Reported by granata.enrico on 2013-10-21 17:40:47

- _Attachment: [asan.cc](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-235/comment-0/asan.cc)_
@ramosian-glider
Copy link
Member Author

Reported by konstantin.s.serebryany on 2013-10-21 18:39:12

@ramosian-glider
Copy link
Member Author

Reported by samsonov@google.com on 2013-10-29 17:10:08

  • Status changed: Accepted

@ramosian-glider
Copy link
Member Author 

I've bisected this to LLVM r185966. Investigating.

Reported by samsonov@google.com on 2013-10-29 18:41:32

@ramosian-glider
Copy link
Member Author 

It seems that revision just exposed the problem described here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131014/191274.html
(and introduced as early as r128327). Long story short,
LLVM CodeGen sometimes incorrectly assumes that expressions which define the location
of a user variable in memory are only valid until the end of a basic block, while instead
they are vaild until the end of the function. This bug hurts plain Clang -O0 debug
info as well, but only occasionally. However, all ASan full debug info is broken because
of that.

Reported by samsonov@google.com on 2013-10-30 00:08:05

@ramosian-glider
Copy link
Member Author 

It would be great to get this fixed, it makes debugging ASAN binaries impossible which
is important of course when analyzing how a memory error occurred.

Is there a workaround possible?

Reported by mrich30 on 2014-05-23 05:24:14

@ramosian-glider
Copy link
Member Author 

I have a patch that fixes this issue for me, and the necessary changes are currently
being reviewed. I can you send you a patch tomorrow, so that you can verify it helps
your debugging. For now I can suggest no reasonable workaround (except for debugging
the binary w/o ASan, or figuring out where the locals are stored by reading assembly,
not nice).

Reported by samsonov@google.com on 2014-05-23 05:41:00

@ramosian-glider
Copy link
Member Author 

Yes, please send me the patch, I will try it out also.



2014-05-23 7:41 GMT+02:00 <address-sanitizer@googlecode.com>:

Reported by mrich30 on 2014-05-23 14:57:01

@ramosian-glider
Copy link
Member Author 

Here's the patch - you'll need to apply it to LLVM trunk andr re-build Clang.

Reported by samsonov@google.com on 2014-05-23 23:29:23

- _Attachment: [zdiff.i235](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-235/comment-8/zdiff.i235)_

@ramosian-glider
Copy link
Member Author 

Any updates here?

Reported by bent.mozilla on 2014-08-27 17:24:40

@ramosian-glider
Copy link
Member Author 

Sorry, I was sure I've updated this bug. I've submitted r210492 a while ago that should
significantly improve the situation with debug info for local variables under ASan.
There are still things to fix, but locals should now mostly work (at least with -O0).
I'm dropping a priority for this bug. Please report if you see / don't see improvements
on your side.

Reported by samsonov@google.com on 2014-08-27 19:40:16

  • Labels added: Priority-Low
  • Labels removed: Priority-Medium

@ramosian-glider
Copy link
Member Author 

Hi,

with clang 3.5 this is still broken for simple cases. I tested on SLES 11 x86_64. Please
see the attached example. A debugger session is pasted in build.sh, and you can also
run build.sh to generate the binary "gtest_asan" which reproduces the problem. Both
a local variable and the "this" pointer get optimized out and can not be displayed
in the debugger.

One precondition seems to be that an external function call must be there, though I
was only able to reproduce it with the gtest framework, but not with a simple extern
function.

Interestingly, the debug information for the local variable is there if compiled with
-O1 ("this" pointer is still optimized out).

I did not test this on trunk yet.

Best regards,
Martin Richtarsky

Reported by mrich30 on 2014-11-25 13:19:44

- _Attachment: [debuginfo.tar.gz](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-235/comment-12/debuginfo.tar.gz)_

@ramosian-glider
Copy link
Member Author

Reported by samsonov@google.com on 2014-11-26 23:05:30

  • Labels added: Priority-High
  • Labels removed: Priority-Low

@ramosian-glider
Copy link
Member Author 

Hi,

just wanted to ask how other people debug ASan reports, is there a workaround for this
bug here? I have found quite a few cases where debugging would have been helpful, in
some cases it is only possible to reason about the error with proper debugging info.
Are there debuggers which work with clang+ASan 3.5? Or is everybody just fixing the
errors with the callstacks?

Thanks and Best regards,
Martin

Reported by mrich30 on 2014-12-29 07:36:15

@ramosian-glider
Copy link
Member Author 

I'm not aware of existing debuggers that workaround this issue with ASan debug info
quality. BTW, if you have tip-of-trunk Clang, you can check if the following compile
flag improves the debug info quality:
  clang++ -fsanitize=address -mllvm -asan-stack-dynamic-alloca=1 my/file.cc
It fixes test case in https://code.google.com/p/address-sanitizer/issues/detail?id=235#c12
for me, and I hope to make this option the default after some testing.

Reported by samsonov@google.com on 2014-12-29 18:54:19

@ramosian-glider
Copy link
Member Author 

Thanks, "-mllvm -asan-stack-dynamic-alloca=1" solves the problem for me aswell. Debug
info is looking good in general.

It also solves a problem I was having with dynamic alloca() code (same as https://code.google.com/p/address-sanitizer/issues/detail?id=138
I guess)

I will test further with the flag. Let me know if I can help in any way to make this
the default.

Best regards,
Martin

Reported by mrich30 on 2014-12-30 12:48:26

@ramosian-glider
Copy link
Member Author 

Thanks for trying this. Please report any problems you encounter. If all goes well,
I hope to flip the default early next year.

Reported by samsonov@chromium.org on 2014-12-30 19:15:49

@ramosian-glider
Copy link
Member Author 

I've flipped the default flag value in LLVM r228336

Reported by samsonov@google.com on 2015-02-05 21:02:21

  • Status changed: Fixed

@ramosian-glider
Copy link
Member Author 

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:13:42

  • Labels added: ProjectAddressSanitizer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Priority-High ProjectAddressSanitizer Status-Fixed Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ramosian-glider