Created attachment 11715 [details] test case It feels like addr2line is not outputting valid file:line compared to GDB. I'll attach my little backtracer. Output is below. when code is optimized -O1, the output shows basic_string.h:176 is _M_data() in that STL file. instead of the regular file and line 1. compile the attached test case 2. run addr2line -e exception4 0x15c1 3. the output below [3] is meant to be exception4.cpp:84 $ ./exception4 Unhandled C++ exception: [vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)] Backtrace: [0]: ./exception4(+0x11da) [0x55cfa17411da] print_trace() exception4.cpp:20 [1]: ./exception4(+0x15c1) [0x55cfa17415c1] test() basic_string.h:176 [2]: ./exception4(+0x1627) [0x55cfa1741627] main exception4.cpp:94 [3]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fe576d0cb97] ?? ??:0 [4]: ./exception4(+0x10ca) [0x55cfa17410ca] _start ??:? Segmentation fault (core dumped) $ $ gdb -c core exception4 GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from exception4...done. [New LWP 3468] Core was generated by `./exception4'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __GI_raise (sig=<optimised out>) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=<optimised out>) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x000055cfa1741508 in print_trace () at exception4.cpp:73 #2 0x000055cfa17415c1 in test () at exception4.cpp:86 #3 0x000055cfa1741627 in main () at exception4.cpp:93
Test case is passing silly arguments to addr2line.
(In reply to Alan Modra from comment #1) > Test case is passing silly arguments to addr2line. Unclear what you mean? Please clarify. Easy to reproduce: addr2line -e exception4 0x15c1
My comment about silly arguments was aimed mostly at [3]. You're passing __libc_start_main+0xe7 as an address. For [2], the address you pass to addr2line is immediately after the call to print_trace. Magic c++ things happen there, the string destructor. Some inlined code from the string destructor appears at that address, so it is corrrect for addr2line to report that code's source file. Not a bug.
(In reply to Alan Modra from comment #3) > My comment about silly arguments was aimed mostly at [3]. You're passing > __libc_start_main+0xe7 as an address. ok, got those removed now. > For [2], the address you pass to addr2line is immediately after the call to > print_trace. Magic c++ things happen there, the string destructor. Some > inlined code from the string destructor appears at that address, so it is > corrrect for addr2line to report that code's source file. > > Not a bug. How does GDB get it right?