Recently, I started having troubles debugging my product with GDB. I found the root of the problem, but not yet a workaround.
My code is written in C++11 with extensive use of meta programming. To catch and fix possible crashes, it is compiled with debug info, which is used for demangling on SIGSEGV handler.
Extending the project made some of the tuples grow pretty big.
I narrowed the problem down to: uncomment one type in one tuple, and catch a SegFault in gdb on loading symbols.
Googling this appeared a to be a tedious task. And debugging gdb with gdb haven't brought more insight either. The only thing I found - is a similar bug, but that tracker states it is fixed and confirmed fixed in my version of gdb (7.7.1)
I'm using Ubuntu 14.04 as a dev-box, Centos7 for production servers, and here is the output of "gdb --args gdb ":
xxx@xxx$ gdb --args gdb ./epayworker
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://ift.tt/KpOJT7;
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://ift.tt/xLrliR;.
Find the GDB manual and other documentation resources online at:
<http://ift.tt/1gENejF;.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gdb...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/gdb ./epayworker
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://ift.tt/KpOJT7;
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://ift.tt/xLrliR;.
Find the GDB manual and other documentation resources online at:
<http://ift.tt/1gENejF;.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./epayworker...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000719da1 in cplus_demangle_print_callback ()
(gdb) bt -25
#0 0x0000000000719da1 in cplus_demangle_print_callback ()
#1 0x0000000000719fb4 in ?? ()
#2 0x000000000071a0c7 in ?? ()
#3 0x000000000071a26e in cplus_demangle_v3 ()
#4 0x000000000070c3c6 in cplus_demangle ()
#5 0x000000000068fdbb in bfd_demangle ()
#6 0x000000000055f269 in symbol_set_names ()
#7 0x00000000005cb985 in prim_record_minimal_symbol_full ()
#8 0x00000000004f82ba in ?? ()
#9 0x00000000004f8b95 in ?? ()
#10 0x000000000056a8d9 in ?? ()
#11 0x000000000056a459 in ?? ()
#12 0x000000000056a9b4 in symbol_file_add ()
#13 0x000000000056aa15 in ?? ()
#14 0x00000000005921be in catch_command_errors_const ()
#15 0x0000000000594da5 in ?? ()
#16 0x000000000059205a in catch_errors ()
#17 0x0000000000595244 in gdb_main ()
#18 0x000000000045391e in main ()
(gdb)
I'm not really excited about changing compiler for the core of our production servers at this stage. And bugs creating limitations to architecture is also not the best thing.
So my questions are: am I missing some type of flag to overcome some internal limitation in gdb? or this is just a bug in gdb? or maybe I should not be afraid and migrate for newer compiler version?
Thanks, for any help with my confusion.
Aucun commentaire:
Enregistrer un commentaire