This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>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
#2  0x0000000100135930 in check_possible_namespace_symbols_loop (
    name=0x105844a3c "AddBlocks::add(PDG*, RegionN*, RegionN*)", len=9, 
    objfile=0x1004957f0) at cp-namespace.c:696
#3  0x000000010017df4c in add_partial_symbol (pdi=0xffffffff7fffd1d0, cu=0x0, 
    namespace=0x0) at dwarf2read.c:1585
#4  0x000000010017dd68 in scan_partial_symbols (info_ptr=0x100babe47 "`", 
    lowpc=0xffffffff7fffd2f8, highpc=0xffffffff7fffd2f0, cu=0xffffffff7fffd300, 
    namespace=0x0) at dwarf2read.c:1411
#5  0x000000010017db0c in dwarf2_build_psymtabs_hard (objfile=0x1004957f0, 
    mainline=98660544) at dwarf2read.c:1293
#6  0x0000000100175c3c in elf_symfile_read (objfile=0x1004957f0, mainline=0)
    at elfread.c:581
#7  0x0000000100086eac in reread_symbols () at symfile.c:2022
#8  0x0000000100092500 in run_command (args=0x0, from_tty=1) at infcmd.c:417
#9  0x000000010003cb10 in do_cfunc (c=0x100432b40, args=0x0, from_tty=1)
    at cli/cli-decode.c:53
#10 0x000000010003ed7c in cmd_func (cmd=0x100432b40, args=0x0, from_tty=1)

both objfile and objfile->cp_namespace_symtab
are non-null and look like they point to reasonable data.


The offending binary's source code is too big to include here.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]