From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 805 invoked by alias); 11 Dec 2008 01:14:14 -0000 Received: (qmail 785 invoked by uid 48); 11 Dec 2008 01:14:14 -0000 Date: Thu, 11 Dec 2008 01:14:00 -0000 Message-ID: <20081211011414.784.qmail@sourceware.org> To: gdb-prs@sources.redhat.com, nobody@sources.redhat.com, pedro@codesourcery.com, tromey@redhat.com From: tromey@redhat.com Reply-To: tromey@redhat.com, gdb-prs@sources.redhat.com, nobody@sources.redhat.com, pedro@codesourcery.com, tromey@redhat.com, gdb-gnats@sources.redhat.com Subject: Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore 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 X-SW-Source: 2008-q4/txt/msg00077.txt.bz2 Synopsis: 'p siginfo->si_addr' doesn't work anymore Responsible-Changed-From-To: unassigned->tromey Responsible-Changed-By: tromey Responsible-Changed-When: Thu Dec 11 01:14:13 2008 Responsible-Changed-Why: I'll fix this. State-Changed-From-To: open->analyzed State-Changed-By: tromey State-Changed-When: Thu Dec 11 01:14:13 2008 State-Changed-Why: Thanks for the valgrind trace. I've looked into it a bit more. I believe the problem is due to yacc lookahead. In particular, while expanding "si_addr", the lexer returns a NAME token for the final "si_addr". Then the lexer calls finished_macro_expansion, which frees the expansion string; then it returns an EOF token. This causes the parser to reduce the final rule, resulting in a call to write_exp_string, which reads from the freed memory. My first thought is that the simplest thing to do would be to make an obstack during parsing, and simply push all the intermediate macro expansions onto it. I suspect this is a latent bug in 6.8, but I don't know how to trigger it. This example does not work, perhaps because the parser decides to reduce at different times (I didn't check that theory). http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2564