Created attachment 11710 [details] test case $ ldd --version ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27 Test case attached $ g++-8 -g -pipe -pthread -O1 -o exception4 exception4.cpp $ ./exception4 Unhandled C++ exception: [vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)] Backtrace: 0x0000000000001573: test() at basic_string.h:176 [1]: ./exception4(+0x1573) [0x55c1fcff3573] 0x00000000000015d9: main at exception4.cpp:93 [2]: ./exception4(+0x15d9) [0x55c1fcff35d9] 0x0000000000000000: ?? ??:0 [3]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f4152662b97] 0x000000000000108a: _start at ??:? [4]: ./exception4(+0x108a) [0x55c1fcff308a] Expected: $ g++-8 -Wall -g -o exception4 exception4.cpp $ ./exception4 Unhandled C++ exception: [vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)] Backtrace: 0x0000000000001505: test() at exception4.cpp:81 [1]: ./exception4(+0x1505) [0x562022cdd505] 0x000000000000156c: main at exception4.cpp:93 [2]: ./exception4(+0x156c) [0x562022cdd56c] 0x0000000000000000: ?? ??:0 [3]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f2923475b97] 0x0000000000000fea: _start at ??:? [4]: ./exception4(+0xfea) [0x562022cdcfea]
I did wonder where the issue lies: eg 1. backtrace_symbols 2. g++ debug symbols 3. addr2line 4. Somewhere else
What is the issue exactly?
(In reply to Andreas Schwab from comment #2) > What is the issue exactly? Hi! I don't know the cause. But GDB is accurate, backtrace_symbols() is *not* accurate. It shows basic_string.h:176 backtrace_symbols() for some reason leads to: basic_string.h:176 is _M_data() in that STL file. Modified SEGV at end of print_trace. I'll attach this test case. $ ./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
Created attachment 11714 [details] testcase with raise(SIGSEGV)
In which way is it not accurate?
(In reply to Andreas Schwab from comment #5) > In which way is it not accurate? Looks like it is addr2line as 55cfa17415c1 correct in both backtrace_symbols and gdb. Appologies, let me create a new ticket for addr2line