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]

Re: gdb/922: Breakpoints give crash, bad behavior w/ C++, gcc 3.2 on Solaris


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

From: Daniel Jacobowitz <drow@mvista.com>
To: dunlop@cadence.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/922: Breakpoints give crash, bad behavior w/ C++, gcc 3.2 on Solaris
Date: Fri, 10 Jan 2003 10:06:35 -0500

 On Fri, Jan 10, 2003 at 02:55:52PM -0000, dunlop@cadence.com wrote:
 > 
 > >Number:         922
 > >Category:       gdb
 > >Synopsis:       Breakpoints give crash, bad behavior w/ C++, gcc 3.2 on Solaris
 > >Confidential:   no
 > >Severity:       critical
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Fri Jan 10 06:58:04 PST 2003
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Doug Dunlop
 > >Release:        GNU gdb 5.3
 > >Organization:
 > >Environment:
 > System:
 >   SunOS humdinger 5.7 Generic_106541-20 sun4u sparc SUNW,Ultra-4
 > 
 > Compiler:
 >   Reading specs from /net/humdinger/usr7/tools/gnu/gcc-3.2.1/install/lib/gcc-lib/sparc-sun-solaris2.7/3.2.1/specs
 >   Configured with: ../gcc-3.2.1/configure --prefix=/net/humdinger/usr7/tools/gnu/gcc-3.2.1/install --enable-threads --enable-languages=c,c++
 >   Thread model: posix
 >   gcc version 3.2.1
 > 
 > GDB:
 >   This GDB was configured as "sparc-sun-solaris2.7".
 > >Description:
 > This may be related to or the same problem as report #706, but I'm not sure.
 > 
 > Unfortunately, I haven't been able to boil this down to something simple, but I describe below a sequence of steps to duplicate the problem. 
 >  
 > It happens with gdb 5.3 and also with 5.2 and 5.1.  It happens with gcc 3.2.1 and gcc 3.2, but not with gcc 2.95.2.
 > 
 > When I run the test case (see info in How-to-Repeat) and give gdb the command "break stage1::addsub" my session looks like:
 > 
 >   ...
 >   There is absolutely no warranty for GDB.  Type "show warranty" for details.
 >   This GDB was configured as "sparc-sun-solaris2.7"...
 >   (gdb) break stage1::addsub
 >   Bus error (core dumped)
 > 
 > and the traceback from the resulting core file looks like:
 > 
 >   #0  finish_block (symbol=0x1010101, listhead=0x253a48, old_blocks=0x1010101, start=72340172838076673, end=72340172838076729, objfile=0x2d6e38)
 >       at /net/humdinger/usr7/tools/gnu/gdb-5.3/gdb-5.3/gdb/buildsym.c:304
 >   #1  0x000fb010 in process_one_symbol (type=36, desc=0, valu=56, name=0x5a1d4b "", section_offsets=0x244400, objfile=0x2d6e38)
 >       at /net/humdinger/usr7/tools/gnu/gdb-5.3/gdb-5.3/gdb/dbxread.c:2782
 >   #2  0x000fad70 in read_ofile_symtab (pst=0x7cadd0) at /net/humdinger/usr7/tools/gnu/gdb-5.3/gdb-5.3/gdb/dbxread.c:2626
 >   #3  0x000fa83c in dbx_psymtab_to_symtab_1 (pst=0x7cadd0) at /net/humdinger/usr7/tools/gnu/gdb-5.3/gdb-5.3/gdb/dbxread.c:2454
 >   #4  0x000fa8fc in dbx_psymtab_to_symtab (pst=0x7cadd0) at /net/humdinger/usr7/tools/gnu/gdb-5.3/gdb-5.3/gdb/dbxread.c:2495
 >   #5  0x00075080 in psymtab_to_symtab (pst=0x7cadd0) at /net/humdinger/usr7/tools/gnu/gdb-5.3/gdb-5.3/gdb/symfile.c:375
 >   #6  0x0007014c in lookup_symbol_aux (name=0xffbee548 "stage1", mangled_name=0x0, block=0x7cadd0, namespace=STRUCT_NAMESPACE, 
 >       is_a_field_of_this=0x0, symtab=0x0) at /net/humdinger/usr7/tools/gnu/gdb-5.3/gdb-5.3/gdb/symtab.c:967
 >   #7  0x0006fc14 in lookup_symbol (name=0xffbee548 "stage1", block=0x0, namespace=STRUCT_NAMESPACE, is_a_field_of_this=0x0, symtab=0x0)
 >   ...
 > 
 > If instead when I run the test case I give gdb the command "break stage1::addsub()" my session looks like:
 > 
 >   ...
 >   There is absolutely no warranty for GDB.  Type "show warranty" for details.
 >   This GDB was configured as "sparc-sun-solaris2.7"...
 >   (gdb) break stage1::addsub()
 >   Breakpoint 1 at 0x2fa754: file stage1.cpp, line 45.
 >   (gdb) run
 >   Starting program: /usr7/tools/gnu/gdbTrouble/3.2.1Compiler/systemc-2.0.1/examples/systemc/pipe/run.x 
 >   Warning:
 >   Cannot insert breakpoint 1.
 >   Error accessing memory address 0x2fa754: I/O error.
 >   The same program may be running in another process.
 >   (gdb) where
 >   #0  0xff3b29c0 in ?? ()
 >   Cannot access memory at address 0x38
 >   (gdb) cont
 >   Continuing.
 >   Warning:
 >   Cannot insert breakpoint 1.
 >   Error accessing memory address 0x2fa754: I/O error.
 >   The same program may be running in another process.
 >   (gdb) 
 > 
 > Finally if I try "break stage1::addsub(void)" I get an error message saying that that function is "not defined".
 > >How-To-Repeat:
 > Sorry, I haven't been able to come up with something simple here and I may not be able to.
 > 
 > The complicated way is as follows:
 > 
 > 1. Download the SystemC 2.0.1 release systemc-2.0.1.tgz from http://www.systemc.org
 > 2. Unpack this release
 > 3. Build it as follows:
 >     cd systemc-2.0.1
 >     mkdir objdir
 >     cd objdir
 >     setenv CXX <g++_3.2_or_3.2.1>
 >     ../configure
 >     <GNU_make>
 >     <GNU_make> install
 > 4. Go to systemc-2.0.1/examples/systemc/pipe
 > 5. Change the Makefile.gcc:
 >      o Replace $(OPT) with $(DEBUG) in CFLAGS
 >      o Make sure 'g++' is resolved to the correct compiler used above
 > 6. Build the executable run.x:
 >      <GNU_make> -f Makefile.gcc
 > 7. Run gdb on the executable run.x and follow the scenarios in the above description.
 
 I don't have a Solaris system, so I get to reproduce these with cross
 debuggers.  Could you send me (off list, not to GNATS!) an affected
 copy of run.x?
 
 I've already got another SystemC/Solaris bug to look at...
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer


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