[Bug 1894166] [NEW] libasan missing debug symbols break debugging
Aleksandar Nikolic
1894166 at bugs.launchpad.net
Thu Sep 3 23:31:33 UTC 2020
Public bug reported:
By default, all symbols are missing from libasan binary that is
installed with this package. This, among other things, effectively
breaks debugging with gdb (and LLDB , but that doesn't matter).
To be able to catch ASAN errors in GDB , one would break on
"__sanitizer::Die" and go from there, but without symbols, this won't
work. Other tools rely on symbol lookups to determine instrumentation
presence , which would fail in this case as well.
For example, without libasan5-dbgsym installed:
(gdb) break __sanitizer::Die
Function "__sanitizer::Die" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__sanitizer::Die) pending.
(gdb) r
...
ASAN REPORT
...
==1802381==ABORTING
[Inferior 1 (process 1802381) exited with code 01]
However, with libasan5-dbgsym installed:
(gdb) break __sanitizer::Die
Breakpoint 1 at 0x7ffff76bc200: file ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc, line 49.
(gdb) r
...
ASAN REPORT
...
==1805058==ABORTING
Breakpoint 1, __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc:49
49 ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc: No such file or directory.
(gdb) bt
#0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc:49
#1 0x00007ffff769d8ec in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffd156, __in_chrg=<optimized out>)
at ../../../../src/libsanitizer/asan/asan_report.cc:185
#2 0x00007ffff769d363 in __asan::ReportGenericError (pc=93824992236075, bp=bp at entry=140737488346576, sp=sp at entry=140737488346560, addr=106034152603909,
is_write=is_write at entry=false, access_size=access_size at entry=1, exp=0, fatal=true) at ../../../../src/libsanitizer/asan/asan_report.cc:192
#3 0x00007ffff769de4b in __asan::__asan_report_load1 (addr=<optimized out>) at ../../../../src/libsanitizer/asan/asan_rtl.cc:116
#4 0x000055555555522b in main ()
(gdb)
In this example, it's fairly obvious that missing symbols will prevent one to put a breakpoint on __sanitizer::Die , but as I mentioned, checks in other tools would fail silently and the issue isn't immediately traceable back to missing symbols.
Since AddressSanitizer is primarily used for debugging anyway, would it
make sense to have libasan with symbols by default?
** Affects: gcc-9 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-9 in Ubuntu.
https://bugs.launchpad.net/bugs/1894166
Title:
libasan missing debug symbols break debugging
Status in gcc-9 package in Ubuntu:
New
Bug description:
By default, all symbols are missing from libasan binary that is
installed with this package. This, among other things, effectively
breaks debugging with gdb (and LLDB , but that doesn't matter).
To be able to catch ASAN errors in GDB , one would break on
"__sanitizer::Die" and go from there, but without symbols, this won't
work. Other tools rely on symbol lookups to determine instrumentation
presence , which would fail in this case as well.
For example, without libasan5-dbgsym installed:
(gdb) break __sanitizer::Die
Function "__sanitizer::Die" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__sanitizer::Die) pending.
(gdb) r
...
ASAN REPORT
...
==1802381==ABORTING
[Inferior 1 (process 1802381) exited with code 01]
However, with libasan5-dbgsym installed:
(gdb) break __sanitizer::Die
Breakpoint 1 at 0x7ffff76bc200: file ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc, line 49.
(gdb) r
...
ASAN REPORT
...
==1805058==ABORTING
Breakpoint 1, __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc:49
49 ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc: No such file or directory.
(gdb) bt
#0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc:49
#1 0x00007ffff769d8ec in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffd156, __in_chrg=<optimized out>)
at ../../../../src/libsanitizer/asan/asan_report.cc:185
#2 0x00007ffff769d363 in __asan::ReportGenericError (pc=93824992236075, bp=bp at entry=140737488346576, sp=sp at entry=140737488346560, addr=106034152603909,
is_write=is_write at entry=false, access_size=access_size at entry=1, exp=0, fatal=true) at ../../../../src/libsanitizer/asan/asan_report.cc:192
#3 0x00007ffff769de4b in __asan::__asan_report_load1 (addr=<optimized out>) at ../../../../src/libsanitizer/asan/asan_rtl.cc:116
#4 0x000055555555522b in main ()
(gdb)
In this example, it's fairly obvious that missing symbols will prevent one to put a breakpoint on __sanitizer::Die , but as I mentioned, checks in other tools would fail silently and the issue isn't immediately traceable back to missing symbols.
Since AddressSanitizer is primarily used for debugging anyway, would
it make sense to have libasan with symbols by default?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1894166/+subscriptions
More information about the foundations-bugs
mailing list