[libsanitizer] Fallback to llvm-symbolizer in PATH

[GoogleCodeExporter]

We're setting the default symbolizer path in Chrome that's relative to the 
build dir. This may not work in the case the application is being ran from a 
different directory.
On the other hand, the user may have llvm-symbolizer in PATH, so we can fall 
back to it if we haven't found the symbolizer.

Original issue reported on code.google.com by ramosian.glider@gmail.com on 22 May 2014 at 7:02

[GoogleCodeExporter]

are you sure this is not working this way already? 

Original comment by konstant...@gmail.com on 22 May 2014 at 10:30

[GoogleCodeExporter]

It does not. If I add llvm-symbolizer to PATH but set 
ASAN_OPTIONS=external_symbolizer_path=asdf I get the following warning:

==24065==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7fffac2c969b at pc 0x4b5748 bp 0x7fffac2c95f0 sp 0x7fffac2c95e8
WRITE of size 1 at 0x7fffac2c969b thread T0
==24065==WARNING: invalid path to external symbolizer!
==24065==WARNING: Failed to use and restart external symbolizer!
    #0 0x4b5747 (/usr/local/google/ssd/chrome-git/src/t+0x4b5747)

Original comment by ramosian.glider@gmail.com on 22 May 2014 at 10:58

[GoogleCodeExporter]

Then don't set ASAN_OPTIONS=external_symbolizer_path=asdf !! 

Original comment by konstant...@gmail.com on 22 May 2014 at 11:05

[GoogleCodeExporter]

I'm talking about the following scenario.
Most often Chrome developers run their binaries from src/, so we may want to 
compile the default external_symbolizer_path into the binary.
However if the working dir is different the devs won't be able to get 
symbolized output despite they may have llvm-symbolizer in $PATH. In this case 
we may want to check for llvm-symbolizer in $PATH if it isn't in 
external_symbolizer_path.

Original comment by ramosian.glider@gmail.com on 22 May 2014 at 11:11

[GoogleCodeExporter]

or we should link chrome with the hermetic symbolizer...

Original comment by konstant...@gmail.com on 22 May 2014 at 11:15

[GoogleCodeExporter]

I disagree with #4. ASAN_OPTIONS=external_symbolizer_path should have a higher 
priority than whatever llvm-symbolizer we find in PATH, because ASAN_OPTIONS 
are overridable by user. Suppose that the user wants to run his code with a new 
version of llvm-symbolizer and runs:
  ASAN_OPTIONS=external_symbolizer_path=my/shiny/new/llvm-symolizer ./a.out
(note that missing "b" in llvm-symbolizer). We should fail hard in this case 
(hey, the path you've provided is wrong!) rather than silently fallback to 
symbolizer in $PATH.

Original comment by samso...@google.com on 22 May 2014 at 6:51