No filename when using llvm-symbolizer with ASan on Mac

[ramosian-glider]

Originally reported on Google Code with ID 207

What steps will reproduce the problem?
1. Build Firefox using the MOZCONFIG=~/mozconfig-asan (attached)
2. Trip https://bugzilla.mozilla.org/show_bug.cgi?id=887499

What is the expected output? What do you see instead?

With ASAN_SYMBOLIZER_PATH=~/llvm/build/Release+Asserts/bin/llvm-symbolizer, all lines
are missing source filenames and line numbers:

    #0 0x1057ac304 in nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&)
(/Users/jruderman/trees/mozilla-central/obj-firefox-asan/dist/Nightly.app/Contents/MacOS/XUL+0x1577304)

With | ~/llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py, all lines have
source filenames and line numbers:

    #0 0x1057a7304 in nsINode::ReplaceOrInsertBefore nsINode.cpp:1616

What version of the product are you using? On what operating system?

* LLVM r185346
* Mac 10.7.5
* Firefox: https://hg.mozilla.org/mozilla-central/rev/4ffb23062b3b

Please provide any additional information below.

Reported by jruderman on 2013-07-02 03:16:31

---

- _Attachment: [mozconfig-asan](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-207/comment-0/mozconfig-asan)_

[ramosian-glider]

Have you checked whether llvm-symbolizer is actually being invoked? E.g. you can replace
llvm-symbolizer with a script and check that. I'm not sure that the path starting with
~ is correctly expanded.

Reported by ramosian.glider on 2013-07-02 08:34:14

• Labels added: OpSys-OSX

[ramosian-glider]

Yes, llvm-symbolizer is being invoked.  Bash expands ~ in FOO=~/bar/.

Without any symbolizer (or with an invalid symbolizer path), I don't even get a function
name:

    #0 0x1057a7304 (/Users/jruderman/trees/mozilla-central/obj-firefox-asan/dist/Nightly.app/Contents/MacOS/XUL+0x1577304)

Reported by jruderman on 2013-07-02 19:32:28

[ramosian-glider]

*sigh*
I'll try some more questions to avoid building a Firefox myself:
1) Does standalone llvm-symbolizer works? Run "./bin/llvm-symbolizer", pass "/Users/jruderman/trees/mozilla-central/obj-firefox-asan/dist/Nightly.app/Contents/MacOS/XUL
0x1577304" to stdin and check if it prints file-line info correctly.
2) Can you check where debug info for the binary is stored? I'm interested in sections
(gobjdump -h) of /Users/jruderman/trees/mozilla-central/obj-firefox-asan/dist/Nightly.app/Contents/MacOS/XUL
and the existence and sections of dSYM-companion file (I think it's expected location
is /Users/jruderman/trees/mozilla-central/obj-firefox-asan/dist/Nightly.app/Contents/MacOS/XUL.dSYM/Contents/Resources/DWARF/XUL).

Reported by samsonov@google.com on 2013-07-03 10:28:50

[ramosian-glider]

I'm also seeing something similar with my programs (if it's any indication it's C code).
Moreover I've got the same issue #92 concerning symbolize of lib.

Reported by mkvtoolnix.build.jonthn on 2013-07-05 14:50:40

[ramosian-glider]

Can you provide data similar to what I asked in https://code.google.com/p/address-sanitizer/issues/detail?id=207#c3?

Reported by samsonov@google.com on 2013-07-05 15:32:36

[ramosian-glider]

I will do it next week. Didn't had time today for it.

Reported by mkvtoolnix.build.jonthn on 2013-07-05 18:45:34

[ramosian-glider]

1) Gives me :

functionName
??:0:0

2) The output of "gobjdump -h" below : 

program:     file format mach-o-i386

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         000a3960  000028d0  000028d0  000018d0  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .cstring      00005c82  000a6230  000a6230  000a5230  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .const        00006a44  000abec0  000abec0  000aaec0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .symbol_stub  00000360  000b2904  000b2904  000b1904  2**1
                  CONTENTS, ALLOC, LOAD, CODE
  4 __TEXT.__stub_helper 00000924  000b2c64  000b2c64  000b1c64  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 __TEXT.__unwind_info 00000178  000b3590  000b3590  000b2590  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .eh_frame     000028f0  000b3708  000b3708  000b2708  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .dyld         0000001c  000b6000  000b6000  000b5000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .mod_init_func 00000064  000b601c  000b601c  000b501c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .non_lazy_symbol_pointer 000000a8  000b6080  000b6080  000b5080  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .lazy_symbol_pointer 00000240  000b6128  000b6128  000b5128  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .const_data   00000100  000b6380  000b6380  000b5380  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 12 .data         000032a8  000b6480  000b6480  000b5480  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 13 .mod_term_func 00000048  000b9728  000b9728  000b8728  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 14 .bss          00008aa0  000b9780  000b9780  00000000  2**5
                  ALLOC
 15 __DATA.__common 00000100  000c2220  000c2220  00000000  2**5
                  ALLOC
 16 LC_THREAD.x86_THREAD_STATE32.0 00000040  00000000  00000000  00000650  2**0
                  CONTENTS

In this case it's a static binary (but also got the same problem with dynamically linked
binary). But I don't know (in general) what's this dSYM-companion file.

It's on a Snow Leopard system. 

Reported by mkvtoolnix.build.jonthn on 2013-07-08 06:51:41

[ramosian-glider]

Okay... So indeed your binary doesn't contain debug info sections, and if you've built
it with debug info, it is stored elsewhere. If the path to your binary is /path/to/foo,
do you have "/path/to/foo.dSYM" directory and, specifically, "/path/to/foo.dSYM/Contents/Resources/DWARF/foo"
file?

Which compiler did you use to build the binary - Clang or XCode?

Reported by samsonov@google.com on 2013-07-08 08:00:50

[ramosian-glider]

I'm using clang directly (via Makefile) and I've looked for dSYM but no luck.

So I've rebuilt my binary using latest revision of Clang+Asan (185797)
And I'm still not getting any file/line in asan report using llvm-symbolizer.

I tried loading it in gdb and placing a breakpoint it works correctly and I get
line number & file, so I assume debug informations are present.

I re-ran gobjdump -h on the binary :

program:     file format mach-o-i386

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         0000ee80  00002210  00002210  00001210  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .cstring      00000ca0  00011090  00011090  00010090  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .const        00000008  00011d30  00011d30  00010d30  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .symbol_stub  0000033c  00011d38  00011d38  00010d38  2**1
                  CONTENTS, ALLOC, LOAD, CODE
  4 __TEXT.__stub_helper 000008c4  00012074  00012074  00011074  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 __TEXT.__unwind_info 000000b4  00012940  00012940  00011940  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .eh_frame     00000604  000129f4  000129f4  000119f4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .dyld         0000001c  00013000  00013000  00012000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .mod_init_func 0000000c  0001301c  0001301c  0001201c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .non_lazy_symbol_pointer 00000094  00013028  00013028  00012028  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .lazy_symbol_pointer 00000228  000130bc  000130bc  000120bc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .const_data   00000008  000132e4  000132e4  000122e4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .data         00000038  000132ec  000132ec  000122ec  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 13 .bss          00000d28  00013324  00013324  00000000  2**2
                  ALLOC
 14 __DATA.__common 0000002c  0001404c  0001404c  00000000  2**2
                  ALLOC
 15 LC_THREAD.x86_THREAD_STATE32.0 00000040  00000000  00000000  0000060c  2**0
                  CONTENTS


I'm using "GNU objdump (GNU Binutils) 2.23.2" if it's any information.

Reported by mkvtoolnix.build.jonthn on 2013-07-08 10:35:25