From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18304 invoked by alias); 7 May 2014 08:55:21 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 18271 invoked by uid 48); 7 May 2014 08:55:21 -0000 From: "gbenson at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/14963] segfault on startup Date: Wed, 07 May 2014 08:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 7.5 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gbenson at redhat dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: gbenson at redhat dot com X-Bugzilla-Target-Milestone: 7.7 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q2/txt/msg00196.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=14963 --- Comment #28 from Gary Benson --- 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.