Here is the symbol: _ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4core c++filt also doesn't understand this. You'll note that if I remove the @plt, c++filt does get it. (I've replaced a few characters so that you can't tell what the code is - I really apologize for having doing this - I just don't exactly want it "on the record") I compiled gdb with -g3 -O0, and got this backtrace from its crash [once again with that symbol renamed slightly]. #0 0x082b6859 in d_make_comp (di=0xbf801478, type=DEMANGLE_COMPONENT_CONST, left=0x0, right=0x0) at ./cp-demangle.c:853 #1 0x082b8882 in d_cv_qualifiers (di=0xbf801478, pret=0xbf800090, member_fn=0) at ./cp-demangle.c:2213 #2 0x082b8031 in cplus_demangle_type (di=0xbf801478) at ./cp- #3 0x082b8ffd in d_template_arg (di=0xbf801478) at ./cp-demangle.c:2516 #4 0x082b8ec7 in d_template_args (di=0xbf801478) at ./cp-demangle.c:2468 #5 0x082b6e9c in d_name (di=0xbf801478) at ./cp-demangle.c:1194 #6 0x082b8b00 in d_class_enum_type (di=0xbf801478) at ./cp-demangle.c:2314 #7 0x082b82a8 in cplus_demangle_type (di=0xbf801478) at ./cp- #8 0x082b8ffd in d_template_arg (di=0xbf801478) at ./cp-demangle.c:2516 #9 0x082b8ec7 in d_template_args (di=0xbf801478) at ./cp-demangle.c:2468 #10 0x082b6e9c in d_name (di=0xbf801478) at ./cp-demangle.c:1194 #11 0x082b8b00 in d_class_enum_type (di=0xbf801478) at ./cp-demangle.c:2314 #12 0x082b82a8 in cplus_demangle_type (di=0xbf801478) at ./cp- #13 0x082b8ffd in d_template_arg (di=0xbf801478) at ./cp-demangle.c:2516 #14 0x082b8ec7 in d_template_args (di=0xbf801478) at ./cp-demangle.c:2468 #15 0x082b70bc in d_prefix (di=0xbf801478) at ./cp-demangle.c:1288 #16 0x082b6faf in d_nested_name (di=0xbf801478) at ./cp-demangle.c:1234 #17 0x082b6d94 in d_name (di=0xbf801478) at ./cp-demangle.c:1150 #18 0x082b6c47 in d_encoding (di=0xbf801478, top_level=1) at ./cp- #19 0x082b6b3e in cplus_demangle_mangled_name (di=0xbf801478, top_level=1) at ./cp-demangle.c:1018 #20 0x082bc65d in d_demangle_callback ( mangled=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor options=259, callback=0x82b9d5b <d_growable_string_callback_adapter>, opaque=0xbf8014f4) at ./cp-demangle.c:4545 #21 0x082bc783 in d_demangle ( mangled=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor options=259, palc=0xbf801534) at ./cp-demangle.c:4594 #22 0x082bc7e3 in cplus_demangle_v3 ( mangled=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor options=259) at ./cp-demangle.c:4751 #23 0x082af7dc in cplus_demangle ( mangled=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor options=3) at ./cplus-dem.c:862 #24 0x0810ff5a in symbol_find_demangled_name (gsymbol=0xbf3203c, mangled=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor at symtab.c:476 #25 0x08110261 in symbol_set_names (gsymbol=0xbf3203c, linkage_name=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor len=144, objfile=0x882fec8) at symtab.c:599 #26 0x0804f1fc in prim_record_minimal_symbol_and_info ( name=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor address=3072686080, ms_type=mst_text, section=11, bfd_section=0x86451a4, objfile=0x882fec8) at minsyms.c:798 #27 0x080cb7cc in record_minimal_symbol ( name=0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor address=3072686080, ms_type=mst_text, bfd_section=0x86451a4, objfile=0x882fec8) at elfread.c:174 #28 0x080cbf07 in elf_symtab_read (objfile=0x882fec8, type=2, number_of_symbols=69315, symbol_table=0xb32d880) at elfread.c:502 #29 0x080cc3d3 in elf_symfile_read (objfile=0x882fec8, mainline=0) at elfread.c:666 #30 0x08117fbb in syms_from_objfile (objfile=0x882fec8, addrs=0x84e8ed0, offsets=0x0, num_offsets=0, add_flags=8) at symfile.c:889 #31 0x08118171 in symbol_file_add_with_addrs_or_offsets (abfd=0x85fbe88, add_flags=8, addrs=0x84e8ed0, offsets=0x0, num_offsets=0, flags=2) at symfile.c:990 #32 0x081183c3 in symbol_file_add_from_bfd (abfd=0x85fbe88, add_flags=8, addrs=0x84e8ed0, flags=2) at symfile.c:1091 #33 0x0806d7bd in symbol_add_stub (so=0x84df588, flags=8) at solib.c:459 #34 0x0806d8b9 in solib_read_symbols (so=0x84df588, flags=8) at solib.c:489 #35 0x0806dcbe in solib_add (pattern=0x0, from_tty=0, target=0x8423020, readsyms=1) at solib.c:750 #36 0x0812e2a2 in handle_inferior_event (ecs=0xbfffec0c) at infrun.c:3581 #37 0x0812b969 in wait_for_inferior (treat_exec_as_sigtrap=0) at infrun.c:2050 #38 0x0812b08d in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:1652 #39 0x0812540c in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at infcmd.c:577 #40 0x0812543c in run_command (args=0x0, from_tty=1) at infcmd.c:587 #41 0x080a7cd7 in do_cfunc (c=0x844bff0, args=0x0, from_tty=1) at ./cli/cli-decode.c:67 #42 0x080aa447 in cmd_func (cmd=0x844bff0, args=0x0, from_tty=1) at ./cli/cli-decode.c:1738 #43 0x08050c16 in execute_command (p=0x84249a3 "", from_tty=1) at top.c:453 #44 0x0814065a in command_handler (command=0x84249a0 "") at event-top.c:511 #45 0x08140cae in command_line_handler (rl=0x8459998 "\250\231E\b\30\201X\b") at event-top.c:736 #46 0x08221344 in rl_callback_read_char () at callback.c:205 #47 0x0813fdcf in rl_callback_read_char_wrapper (client_data=0x0) at event- #48 0x08140528 in stdin_event_handler (error=0, client_data=0x0) at event- #49 0x0813f264 in handle_file_event (data=...) at event-loop.c:812 #50 0x0813e9c3 in process_event () at event-loop.c:394 #51 0x0813ea9b in gdb_do_one_event (data=0x0) at event-loop.c:459 #52 0x081398ff in catch_errors (func=0x813e9d8 <gdb_do_one_event>, func_args=0x0, errstring=0x82f0c17 "", mask=6) at exceptions.c:510 #53 0x080bb07f in tui_command_loop (data=0x0) at ./tui/tui-interp.c:153 #54 0x08139eb0 in current_interp_command_loop () at interps.c:291 #55 0x08048510 in captured_command_loop (data=0x0) at ./main.c:226 #56 0x081398ff in catch_errors (func=0x8048505 <captured_command_loop>, func_args=0x0, errstring=0x82d6609 "", mask=6) at exceptions.c:510 #57 0x08049458 in captured_main (data=0xbffff130) at ./main.c:902 #58 0x081398ff in catch_errors (func=0x8048546 <captured_main>, func_args=0xbffff130, errstring=0x82d6609 "", mask=6) at exceptions.c:510 #59 0x0804948e in gdb_main (args=0xbffff130) at ./main.c:911 #60 0x08048287 in main (argc=2, argv=0xbffff1e4) at gdb.c:33 If I do an "nm" on the library containing that symbol, it does exist (but without the @plt) - I guess it's not that the demangler is wrong, but that the @plt doesn't belong in that symbol to begin with. What's strange is that at the line of code that it crashes at, there's really nothing that could cause that: p = d_make_empty (di); 0x082b684b <d_make_comp+75>: jmp 0x82b688a <d_make_comp+138> 0x082b684d <d_make_comp+77>: movl $0x0,-0x14(%ebp) 0x082b6854 <d_make_comp+84>: jmp 0x82b688a <d_make_comp+138> 0x082b6856 <d_make_comp+86>: mov 0x8(%ebp),%eax 0x082b6859 <d_make_comp+89>: mov %eax,(%esp) 0x082b685c <d_make_comp+92>: call 0x82b67aa <d_make_empty> Weird, huh. Here's `print *di`: { s = 0xb48c4f2f "_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7nbbbbbb4cor send = 0xb48c4fbf "", options = 259, n = 0xb48c4f67 "PKN4maaa7nbbbbbb4core9IddddddddEPNS3_10seeeeeeeee3bff13Fgggggggggggg7Shhhhhh subs = 0xbf800430, next_sub = 4, num_subs = 144, did_subs = 0, last_name = 0xbf8006c8, expansion = 12} Please let me know if you need more information, I can also provide realtime information on IRC if you ask.
There is no @plt in the backtrace anywhere and a lot of lines appear to be cut off at the end.
Strange, it seems bugzilla cut it off, here is the complete symbol: _ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4maaa7 nbbbbbb4core9IccccccccEPNS3_10sddddddddd3bee13Fffffffffffff7Sggg gggEEEED2Ev@plt (manually wordwrapped) Anywhere you see the cutoff symbol, just use the above one in its place and everything should be complete as a result. Apologies and thanks.
Using a relatively recent CVS binutils, I was unable to make c++filt crash on this symbol, with or without the @plt: opsy. ~/gnu/baseline-gdb/build/binutils/cxxfilt < symname __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<maaa::nbbbbbb::core::Icccccccc const* const, maaa::sddddddddd::bee::Fffffffffffff::Sgggggg*> > >::~new_allocator() __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<maaa::nbbbbbb::core::Icccccccc const* const, maaa::sddddddddd::bee::Fffffffffffff::Sgggggg*> > >::~new_allocator()@plt Could you try a CVS gdb on your program? Maybe the bug has been fixed.
I was never able to make c++filt crash on it either. It's a problem in gdb itself. I tried to create a testcase .so that gdb crashes on which it demangles this symbol, but to no avail.
Could you possible try with gdb master? We changed some things in how demangling is done so now it will line up a bit better with c++filt and other binutils. I tend to doubt it will help but it is worth a try.
I'm afraid I no longer have this source code, nor even remember where it came from if I did have the code. I guess you can close this bug.
Confirmed current GDB doesn't crash on this. The demangler was clearly fixed meanwhile. GDB ("maint demangle") demangles it as: __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<maaa::nbbbbbb::core::Icccccccc const* const, maaa::sddddddddd::bee::Fffffffffffff::Sgggggg*> > >::~new_allocator()@plt Closing then. Thanks.