Bug 14963

Summary: segfault on startup
Product: gdb Reporter: Sam Varshavchik <mrsam>
Component: gdbAssignee: Gary Benson <gbenson>
Status: RESOLVED FIXED    
Severity: normal CC: adrian.cheater, gbenson, jakub, jeremy, keiths, mingw.android, nwknize, pedro, pinskia, tromey
Priority: P2    
Version: 7.8   
Target Milestone: ---   
See Also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55880
Host: x86_64-w64-mingw32 Target:
Build: Last reconfirmed:
Attachments: Reproducer
Dump of parsed tree, and backtrace showing loop
Nick's test code, from http://pastebin.com/PwGjNH1N
Nick's compilation flags, from http://pastebin.com/ry7WLw2g
3 failed strings from test-demangle when gdb 7.7 was configured with CFLAGS='-DCP_DEMANGLE_DEBUG -ggdb3 -O0'

Description Sam Varshavchik 2012-12-16 02:28:39 UTC
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.
Comment 1 Tom Tromey 2012-12-16 02:42:31 UTC
Looks like infinite recursion in the demangler.
Comment 2 Sam Varshavchik 2012-12-16 02:48:53 UTC
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
Comment 3 Tom Tromey 2012-12-17 15:05:11 UTC
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.
Comment 4 Gary Benson 2013-08-30 12:25:54 UTC
Created attachment 7176 [details]
Reproducer

gcc -I/path/to/src/include test.c /path/to/build/libiberty/libiberty.a -o test
Comment 5 Gary Benson 2013-09-03 09:38:58 UTC
For reference the ABI spec wrt mangling is here:
http://mentorembedded.github.io/cxx-abi/abi.html#mangling
Comment 6 Gary Benson 2013-09-03 09:45:27 UTC
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?
Comment 7 Gary Benson 2013-09-04 14:33:24 UTC
Possible fix:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00215.html
Comment 8 Gary Benson 2013-09-10 12:37:39 UTC
Fix committed to GCC SVN:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=202442
Comment 9 Gary Benson 2013-09-11 12:24:16 UTC
Fix reverted from GCC :(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58386
Comment 10 Gary Benson 2013-11-04 16:28:41 UTC
New fix committed to GCC SVN:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204068
Comment 12 Jakub Jelinek 2013-12-06 15:32:21 UTC
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?
Comment 13 Gary Benson 2013-12-12 10:37:56 UTC
I am working on a fix for this here:
https://github.com/gbenson/binutils-gdb/tree/demangler
Comment 14 Gary Benson 2014-01-06 14:31:45 UTC
Updated fix committed to GCC SVN:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=206362
Comment 15 Tom Tromey 2014-02-18 20:51:20 UTC
Fixed.
Comment 16 Jeremy Maitin-Shepard 2014-02-23 19:08:38 UTC
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.
Comment 17 Gary Benson 2014-03-19 10:30:45 UTC
Ok, I see this too.
Comment 18 Nick K 2014-03-24 18:53:51 UTC
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
Comment 19 Gary Benson 2014-03-24 19:55:52 UTC
Thanks Nick.
Comment 20 Pedro Alves 2014-03-25 09:57:41 UTC
Thanks Nick.  Note that it's best to attach files to the bug, rather than rely on pastebin being around forever.
Comment 21 Gary Benson 2014-03-26 11:32:42 UTC
Created attachment 7491 [details]
Nick's test code, from http://pastebin.com/PwGjNH1N
Comment 22 Gary Benson 2014-03-26 11:33:22 UTC
Created attachment 7492 [details]
Nick's compilation flags, from http://pastebin.com/ry7WLw2g
Comment 23 Gary Benson 2014-03-26 14:16:38 UTC
It's highly likely bug 16752 is the same issue as this.
Comment 24 Keith Seitz 2014-03-28 21:12:53 UTC
Also c++/16593. Problematic mangling:
_ZNSt9_Any_data9_M_accessIPZN3sel8Selector6SetObjI3FooJPKcMS4_FviEEEEvRT_DpT0_EUlvE_EESA_v
Comment 25 Adrian Cheater 2014-05-01 17:56:25 UTC
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?
Comment 26 Gary Benson 2014-05-02 08:30:50 UTC
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.
Comment 27 Adrian Cheater 2014-05-05 20:21:21 UTC
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
Comment 28 Gary Benson 2014-05-07 08:55:18 UTC
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.
Comment 29 Gary Benson 2014-05-07 09:14:54 UTC
FWIW I have a fix that works for everything but the symbol in comment 16.
Comment 30 Gary Benson 2014-05-07 09:16:42 UTC
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...
Comment 31 Gary Benson 2014-05-07 15:44:04 UTC
Patch mailed:
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00404.html
Comment 32 Gary Benson 2014-05-08 09:15:38 UTC
Fix committed to GCC SVN:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210205
Comment 33 Ray Donnelly 2014-08-20 22:50:11 UTC
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
Comment 34 Gary Benson 2014-08-27 09:09:19 UTC
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.
Comment 35 Gary Benson 2014-08-27 09:09:35 UTC
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.