Re: symtab/1534: gdb current segfaults when debugee a.out changes

[Daniel Jacobowitz <drow at mvista dot com>]

The following reply was made to PR symtab/1534; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@mvista.com>
To: rrh@cray.com, carlton@kealia.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: symtab/1534: gdb current segfaults when debugee a.out changes
Date: Fri, 23 Jan 2004 09:51:10 -0500

 Thanks for the report!
 
 On Thu, Jan 22, 2004 at 11:05:10PM -0000, rrh@cray.com wrote:
 > 
 > >Number:         1534
 > >Category:       symtab
 > >Synopsis:       gdb current segfaults when debugee a.out changes
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          change-request
 > >Submitter-Id:   net
 > >Arrival-Date:   Thu Jan 22 23:08:01 UTC 2004
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     rrh@cray.com
 > >Release:        GNU gdb 2004-01-16-cvs
 > >Organization:
 > >Environment:
 > sun solaris 5.8 gdb compiled with gcc 3.2.2 -m64
 > >Description:
 > I compiled the gdb 2004-01-16-cvs gdb release --target=sparcv9-sun-solaris2.8
 > with Makefile edited to use gcc 3.2.2, invoking gcc 3.2.2
 > with the -m64 flag (so that I can debug 64-bit pointer binaries; see     http://sources.redhat.com/ml/bug-gdb/2001-01/msg00073.html
 > for inspiration)
 > 
 > I then run the resulting gdb on a large debuggee binary. 
 > The binary runs to its faulting place; I relink the binary, and tell the gdb debugger to rerun; it realizes that the binary has changed and starts to reread the binary.
 > gdb then segfaults.  the first 10 frames of backtrace of the failing gdb are (I ran gdb under itself) as follows.
 > Neither 
 > #0  0x0000000100135808 in get_possible_namespace_block (objfile=0x1004957f0)
 >     at cp-namespace.c:634
 > #1  0x0000000100135954 in check_one_possible_namespace_symbol (name=0x1004957f0 "", 
 >     len=9, objfile=0x1004957f0) at cp-namespace.c:712
 
 > #7  0x0000000100086eac in reread_symbols () at symfile.c:2022
 
 > both objfile and objfile->cp_namespace_symtab
 > are non-null and look like they point to reasonable data.
 
 David,
 
 I'm pretty sure this is yours.  The symtab is on the objfile's
 obstacks, which are wiped when it is reloaded, so you probably need to
 wipe the symtab pointer too.  See reread_symbols.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer