Big C++ hairball built by gcc 4.7.2 with -std=c++0x (x86_64, fedora 17) makes gdb very sad: GNU gdb (GDB) 7.5.50.20121215 Copyright (C) 2012 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-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/mrsam/src/libcxx/base/testmimebodystartiter...Segmentation fault (core dumped) The binary that's causing this is 23mb uncompressed, 6.5mb compressed. You can download this binary here: http://www.libcxx.org/ref/testmimebodystartiter.gz.bin This is gzip-compressed. Let me know when you grabbed it, so I can get rid of it.
Looks like infinite recursion in the demangler.
Indeed. Running gdb Yeah, just got the bright idea myself, to try gdb-ing gdb itself, and this seems to be the loop: #158 0x00000000006db266 in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff95d8) at ../../libiberty/cp-demangle.c:4337 #159 0x00000000006d9965 in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff9668) at ../../libiberty/cp-demangle.c:3936 #160 0x00000000006d9fca in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff9680) at ../../libiberty/cp-demangle.c:4325 #161 0x00000000006d9965 in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff96b0) at ../../libiberty/cp-demangle.c:3936 #162 0x00000000006d9fca in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff96c8) at ../../libiberty/cp-demangle.c:4325 #163 0x00000000006d9965 in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff96e0) at ../../libiberty/cp-demangle.c:3936 #164 0x00000000006d9190 in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff96f8) at ../../libiberty/cp-demangle.c:4147 #165 0x00000000006d9fca in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff9620) at ../../libiberty/cp-demangle.c:4325 #166 0x00000000006d9965 in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff9638) at ../../libiberty/cp-demangle.c:3936 #167 0x00000000006d9fca in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff9650) at ../../libiberty/cp-demangle.c:4325 #168 0x00000000006db266 in d_print_comp (dpi=0x7fffffff7e50, options=259, dc=0x7fffffff95d8) at ../../libiberty/cp-demangle.c:4337
The failing symbol name is _ZSt7forwardIRN1x14refobjiteratorINS0_3refINS0_4mime30multipart_section_processorObjIZ15get_body_parserIZZN14mime_processor21make_section_iteratorERKNS2_INS3_10sectionObjENS0_10ptrrefBaseEEEbENKUlvE_clEvEUlSB_bE_ZZNS6_21make_section_iteratorESB_bENKSC_clEvEUlSB_E0_ENS1_INS2_INS0_20outputrefiteratorObjIiEES8_EEEERKSsSB_OT_OT0_EUlmE_NS3_32make_multipart_default_discarderISP_EEEES8_EEEEEOT_RNSt16remove_referenceISW_E4typeE BTW you can delete your test program now.
Created attachment 7176 [details] Reproducer gcc -I/path/to/src/include test.c /path/to/build/libiberty/libiberty.a -o test
For reference the ABI spec wrt mangling is here: http://mentorembedded.github.io/cxx-abi/abi.html#mangling
Created attachment 7185 [details] Dump of parsed tree, and backtrace showing loop There seems to be a loop in the parsed tree, starting at dc 0x7fffffff9dc0 in this backtrace. A substitution is referencing itself?
Possible fix: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00215.html
Fix committed to GCC SVN: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=202442
Fix reverted from GCC :( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58386
New fix committed to GCC SVN: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204068
Fixed: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9548bbede51868a9a780d7d21ae16ac13e8bdf9b
Unfortunately even the second patch is incorrect, at least when the *_callback APIs are used, the demangler is not supposed to use any malloc/free. Can the amount of total needed memory for this be determined e.g. at the time when the component tree is created, so that cplus_demangle_print_callback would then just alloca all the memory needed for that at once before calling d_print_comp?
I am working on a fix for this here: https://github.com/gbenson/binutils-gdb/tree/demangler
Updated fix committed to GCC SVN: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=206362
Fixed.
I think there is still a related problem: GNU gdb (GDB) 7.7.50.20140223-cvs I am getting infinite recursion in d_print_comp, seemingly caused by the symbol: _ZN3mdr16in_cached_threadIRZNK4cudr6GPUSet17parallel_for_eachIZN5tns3d20shape_representation7compute7GPUImpl7executeERKNS_1AINS_7ptr_refIKjEELl3ELl3ENS_8c_strideILl1ELl0EEEEERKNS8_INS9_IjEELl4ELl1ESD_EEEUliRKNS1_7ContextERNS7_5StateEE_JSt6vectorISO_SaISO_EEEEEvOT_DpRT0_EUlSP_E_JSt17reference_wrapperISO_EEEENS_12ScopedFutureIDTclfp_spcl7forwardISW_Efp0_EEEEESV_DpOSW_ c++filt is able to demangle it. GNU c++filt (GNU Binutils) 2.24 However, the maint demangle command just says Can't demangle but doesn't crash.
Ok, I see this too.
I'm also getting a stack overflow in cp-demangle.c function d_print_comp (case DEMANGLE_COMPONENT_VECTOR_TYPE:). The exact line of the segfault is 4876. The mangled string causing the issue is _ZNSt9_Any_data9_M_accessIPZN13ThreadManager10futureTaskISt5_BindIFSt7_Mem_fnIM6RunnerFvvEEPS5_EEEEvOT_EUlvE_EERSC_v Here is the test code that causes the issue: http://pastebin.com/PwGjNH1N Here are the compilation flags: http://pastebin.com/ry7WLw2g
Thanks Nick.
Thanks Nick. Note that it's best to attach files to the bug, rather than rely on pastebin being around forever.
Created attachment 7491 [details] Nick's test code, from http://pastebin.com/PwGjNH1N
Created attachment 7492 [details] Nick's compilation flags, from http://pastebin.com/ry7WLw2g
It's highly likely bug 16752 is the same issue as this.
Also c++/16593. Problematic mangling: _ZNSt9_Any_data9_M_accessIPZN3sel8Selector6SetObjI3FooJPKcMS4_FviEEEEvRT_DpT0_EUlvE_EESA_v
Created attachment 7573 [details] 3 failed strings from test-demangle when gdb 7.7 was configured with CFLAGS='-DCP_DEMANGLE_DEBUG -ggdb3 -O0' The pattern I'm seeing is when the parser hits the "reference->template parameter 0" sections of the tree. It's grabbing a reference point of which it is a subnode. Causing the parser to cycle back and recurse until it runs out of stack or heap. I'm still trying to get my head around this, having only started looking into it about 2 days ago, but I have the following hypothesies. - It's adding a reference to the near root of the tree when it shouldn't be (which ends up as reference 0) - The 'template parameter 0's might need to be 'template parameter 1's. - References are allowed to be recursive, and at the time it fetches 'template parameter 0', it's not grabbing the correct level. Hoping someone with more experience can help me narrow it down, otherwise I'm going to keep investigating. This bug is blocking a hobby project of mine, so it's either fix this or shelve the project until someone else fixes it. At any rate, the problem is likely to be somewhere in the get/set symbol references but I don't know what the 'correct' behaviour is supposed to be. Is this defined in a spec, or just a undefined detail?
Adrian, the mangling spec is here: http://mentorembedded.github.io/cxx-abi/abi.html#mangling I don't pretend to understand it all :) You may be interested in this patch to unblock your hobby project: https://sourceware.org/ml/gdb-patches/2014-04/msg00156.html It (should) allow GDB to continue in the face of demangler failures. If you try it please let me know how you get on.
Thanks Gary, I'm reading through it now and trying to hand parse the crashing strings to see what they should be, and then see if I can figure out where the parser is dying. On that note however, since the spec is a BNF grammar. Is there a reason the demangler isn't implemented in GNU Bison or something? I saw a reference that a YACC based system used to be part of GCC, but was dropped (for what I assume are very good reasons). Should I assume that a Bison based demangler would not be accepted (though I suppose I could use it as a reference implementation). This definitely seems like a bug in the substitution part of the spec, though I haven't determined if the bug is in the DC compiler, or the printer callback. Might be related to templates within templates. http://mentorembedded.github.io/cxx-abi/abi.html#mangle.substitution
The fix that caused the new crashes (linked in comment 14) alters how substitution is performed, so yeah, it seems likely that the bug is related to substitution somehow. That patch is definitely a place to start looking. FWIW I'm trying to fix this too, but two minds working on it is definitely better than one :) Here's a summary I sent in a private mail to one of the libiberty guys: > The original bug was that the symbol in > https://sourceware.org/bugzilla/show_bug.cgi?id=14963#c3 > would crash the demangler. I made a fix for this which is now > upstream in GCC libiberty, but that fix seems to be causing > the demangler to crash on other symbols, specifically > https://sourceware.org/bugzilla/show_bug.cgi?id=14963#c16, > https://sourceware.org/bugzilla/show_bug.cgi?id=14963#c18 and > https://sourceware.org/bugzilla/show_bug.cgi?id=16752#c1. > > The original crash is something to do with how references to template > parameters are handled within substitutions. The actual design of the > demangler seems to contain a conflict (as I understand it) between: > > 1) Templates are stored on a stack as the tree is walked. When a > template is referenced it is pulled off this stack. > > 2) Substitutions are expanded *before* the tree is walked. > > The way substitutions are implemented means that the same nodes > (specifically, the same struct dc_component instances) appear > multiple times in the parsed tree. The point in the tree that > was the "original" will have the correct template stack. The > others, the nodes that came from substitutions, may not have > the correct stack. > > The fix I made (that is now in GCC libiberty) was to store the > template stack the first time a reference is encountered, and to > restore them temporarily on subsequent encounters. This allows > the original symbol to be demangled but I have no idea if the > result is correct. I tried to work it out manually but I got lost > and in any event I couldn't tell if I was interpreting the spec > correctly. > > My gut feeling is that the original fix is wrong and should be > backed out, but I don't feel able to propose this on the GCC list > on that basis. I'm basically out of my depth here! WRT Bison, I don't know the history here. Maybe this would be a good question for gdb@sourceware.org, or maybe one of the GCC lists. It's a pain that libiberty doesn't have its own list somewhere! Note that because of the way it is included in parts of GCC the demangler can never allocate heap, so no calls to malloc, etc. It's possible this is why the demangler is written like this rather than using a parser generator.
FWIW I have a fix that works for everything but the symbol in comment 16.
Sorry, sent too soon... I have a fix that works for everything but the symbol in comment 16 BUT it changes the demangled result. So, Adrian, if you manage to hand-parse even one of the demangled symbols, that would be really useful :) I tried, but I don't know C++ well enough...
Patch mailed: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00404.html
Fix committed to GCC SVN: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210205
I ran into the a similar infinite-loop-with-segfault-when-stack-is-all-chewed-up today on MSYS2 when gdb attempted to demangle: _ZN5Utils9transformIPN15ProjectExplorer13BuildStepListEZNKS1_18BuildConfiguration14knownStepListsEvEUlS3_E_EE5QListIDTclfp0_cvT__EEEERKS6_IS7_ET0_ Here's the callstack: #51406 0x00000000007ff38f in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d178) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5115 #51407 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d178) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51408 0x00000000007ff963 in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d190) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5276 #51409 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d190) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51410 0x00000000007fdceb in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d0e8) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4537 #51411 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d0e8) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51412 0x0000000000800735 in d_print_cast (dpi=0x2e9c7f0, options=259, dc=0x2e9d100) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5754 #51413 0x00000000007fefe3 in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d130) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5046 #51414 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d130) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51415 0x00000000007febcf in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d148) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4950 #51416 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d148) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51417 0x00000000007fd187 in d_print_subexpr (dpi=0x2e9c7f0, options=259, dc=0x2e9d148) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4228 #51418 0x00000000007ff38f in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d178) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5115 #51419 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d178) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51420 0x00000000007ff963 in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d190) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5276 #51421 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d190) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51422 0x00000000007fdceb in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d0e8) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4537 #51423 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d0e8) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51424 0x0000000000800735 in d_print_cast (dpi=0x2e9c7f0, options=259, dc=0x2e9d100) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5754 #51425 0x00000000007fefe3 in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d130) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5046 #51426 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d130) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51427 0x00000000007febcf in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d148) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4950 #51428 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d148) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51429 0x00000000007fd187 in d_print_subexpr (dpi=0x2e9c7f0, options=259, dc=0x2e9d148) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4228 #51430 0x00000000007ff38f in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d178) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5115 #51431 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d178) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51432 0x00000000007ff963 in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d190) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5276 #51433 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d190) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51434 0x00000000007febcf in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d1a8) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4950 #51435 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d1a8) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51436 0x00000000007fdbcc in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d1c0) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4501 #51437 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d1c0) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51438 0x00000000007fe766 in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d280) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4820 #51439 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d280) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51440 0x00000000007fd9bd in d_print_comp_inner (dpi=0x2e9c7f0, options=259, dc=0x2e9d298) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4442 #51441 0x00000000007ffccf in d_print_comp (dpi=0x2e9c7f0, options=259, dc=0x2e9d298) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5368 #51442 0x00000000007fce21 in cplus_demangle_print_callback (options=259, dc=0x2e9d298, callback=0x7fc7ef <d_growable_string_callback_adapter>, opaque=0x2e9eb20) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:4071 #51443 0x0000000000800c45 in d_demangle_callback ( mangled=0x3ac6ae5c "_ZN5Utils9transformIPN15ProjectExplorer13BuildStepListEZNKS1_18BuildConfiguration14knownStepListsEvEUlS3_E_EE5QListIDTclfp0_cvT__EEEERKS6_IS7_ET0_", options=259, callback=0x7fc7ef <d_growable_string_callback_adapter>, opaque=0x2e9eb20) at E:/m2/repo/mingw-w64-gdb/src/gdb-7.8/libiberty/cp-demangle.c:5898
Ray, I filed your issue as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 Please Cc yourself there if you want to track it. I'm closing this bug, the original issue it related to is fixed.
Please nobody reopen this bug again: * If you have a demangler crash and you know the symbol, please file in GCC bugzilla like this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 * If you have a demangler crash and you don't know the symbol, please file a new bug here and I will triage it. Thanks.