asan woes with addr2line

[Andrew Scherkus]

I'm running into some snafus running asan_symbolize.py @ r157144 and after trying many different things I'm throwing in towel.

Everything seemingly builds and runs fine and ASAN will crash w/ a stack trace as expected:

$ out/Debug/base_unittests --gtest_filter=ToolsSanityTest.DISABLED_AddressSanitizerLocalOOBCrashTest --gtest_also_run_disabled_tests 2>&1

Note: Google Test filter = ToolsSanityTest.DISABLED_AddressSanitizerLocalOOBCrashTest

[==========] Running 1 test from 1 test case.

[----------] Global test environment set-up.

[----------] 1 test from ToolsSanityTest

[ RUN      ] ToolsSanityTest.DISABLED_AddressSanitizerLocalOOBCrashTest

=================================================================

==29195== ERROR: AddressSanitizer stack-buffer-overflow on address 0x7fff3f067714 at pc 0x126090b bp 0x7fff3f067610 sp 0x7fff3f067608

WRITE of size 4 at 0x7fff3f067714 thread T0

    #0 0x126090a (/usr/local/google/scherkus/chrome/src/out/Debug/base_unittests+0x126090a)

    #1 0x147e072 (/usr/local/google/scherkus/chrome/src/out/Debug/base_unittests+0x147e072)

    #2 0x1439977 (/usr/local/google/scherkus/chrome/src/out/Debug/base_unittests+0x1439977)

...

However attempting to run asan_symbolize.py causes addr2line to spam errors ad infinitum:

addr2line -f -e /usr/local/google/scherkus/chrome/src/out/Debug/base_unittests 0x147e072

BFD: Dwarf Error: Invalid or unhandled FORM value: 25.

BFD: Dwarf Error: Invalid or unhandled FORM value: 25.

BFD: Dwarf Error: Invalid or unhandled FORM value: 25.

...

Other settings in case they're relevant:

$ echo $GYP_DEFINES

component="shared_library" asan=1 linux_use_tcmalloc=0 release_extra_cflags="-g -O1 -fno-inline-functions -fno-inline"

$ echo $GYP_GENERATORS

ninja

$ echo $CC $CXX

clang clang++

$ ninja --version

1.0.0

$ clang --version

clang version 3.2 (trunk 163126)

Target: x86_64-unknown-linux-gnu

Thread model: posix

$ addr2line --version

GNU addr2line (GNU Binutils for Ubuntu) 2.20.1-system.20100303

Copyright 2009 Free Software Foundation, Inc.

This program is free software; you may redistribute it under the terms of

the GNU General Public License version 3 or (at your option) any later version.

This program has absolutely no warranty.

Anyone ever see this before or have any ideas?

Andrew

[Ami Fischman]

FWIW, this worked for me 1.5w ago on a glucid laptop, so you might try and roll back clang a roll or two.

-a

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Andrew Scherkus]

On Mon, Sep 17, 2012 at 2:42 PM, Ami Fischman <fisc...@chromium.org> wrote:

FWIW, this worked for me 1.5w ago on a glucid laptop, so you might try and roll back clang a roll or two.

mcgrathr@ replied to me off-list:

That is a binutils version that cannot decode DWARF 4.  More recent binutils versions, such as the one in gPrecise, can decode DWARF 4.

Sure enough I locally rolled back the lastest clang roll [1] and things appear to work. Guess it's time to upgrade :~(

Andrew

[1] thakis@ http://src.chromium.org/viewvc/chrome?view=rev&revision=155953

[Reid Kleckner]

Idea: you can probably keep using Lucid if you find a way to strip the DWARF4 without losing too much info.  I can think of two approaches.

'strip --strip-debug' will leave .symtab, which should be enough to get symbols but no line numbers.

Replace '-g' with '-gline-tables-only' instead.  This will give you line numbers, bug will string all class and namespace qualifiers, so the stack only has method names.

--

[Alexander Potapenko]

On Tue, Sep 18, 2012 at 11:53 AM, Reid Kleckner <r...@google.com> wrote:
> Idea: you can probably keep using Lucid if you find a way to strip the
> DWARF4 without losing too much info. I can think of two approaches.
>
> 'strip --strip-debug' will leave .symtab, which should be enough to get
> symbols but no line numbers.
>
> Replace '-g' with '-gline-tables-only' instead. This will give you line
> numbers, bug will string all class and namespace qualifiers, so the stack
> only has method names.

Good ones!
I don't think -gline-tables-only guarantees the absence of DWARF 4,
but at least there'll be less errors.

BTW I wonder if the symbolization runs faster if we execute addr2line
with 2>/dev/null. Andrew, can you try this? (my addr2line doesn't seem
to complain)

We're going to switch from addr2line to our home-brew symbolizer which
can be used both during program execution and offline. It's based on
LLDB, so it knows about DWARF 4 as much as the compiler does.

[Andrew Scherkus]

On Tue, Sep 18, 2012 at 10:17 AM, Alexander Potapenko <gli...@chromium.org> wrote:

On Tue, Sep 18, 2012 at 11:53 AM, Reid Kleckner <r...@google.com> wrote:
> Idea: you can probably keep using Lucid if you find a way to strip the
> DWARF4 without losing too much info.  I can think of two approaches.
>
> 'strip --strip-debug' will leave .symtab, which should be enough to get
> symbols but no line numbers.
>
> Replace '-g' with '-gline-tables-only' instead.  This will give you line
> numbers, bug will string all class and namespace qualifiers, so the stack
> only has method names.

Good ones!
I don't think -gline-tables-only guarantees the absence of DWARF 4,
but at least there'll be less errors.

BTW I wonder if the symbolization runs faster if we execute addr2line
with 2>/dev/null. Andrew, can you try this? (my addr2line doesn't seem
to complain)

Worked like a charm :)

https://codereview.chromium.org/10943011/

Andrew

[Andrew Scherkus]

FYI the 2>/dev/null fix was landed as http://src.chromium.org/viewvc/chrome?view=rev&revision=157369

Andrew