[Bug gdb/14963] segfault on startup

["gbenson at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=14963

--- Comment #28 from Gary Benson <gbenson at redhat dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.