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: c++/1210: Printing fails/aborts for some attributes (Cannot access memory at address)


The following reply was made to PR c++/1210; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@mvista.com>
To: Milan Schulte <Milan.Schulte@OFFIS.de>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: c++/1210: Printing fails/aborts for some attributes (Cannot access memory at address)
Date: Tue, 20 May 2003 00:09:25 -0400

 On Mon, May 19, 2003 at 06:36:33PM +0200, Milan Schulte wrote:
 > Dear Daniel Jacobowitz,
 > 
 > >On Wed, May 14, 2003 at 02:12:44PM -0000, milan.schulte@offis.de wrote:
 > >
 > >>>Number:         1210
 > >>>Category:       c++
 > >>>Synopsis:       Printing fails/aborts for some attributes (Cannot access 
 > >>>memory at address)
 > >>>Confidential:   no
 > >>>Severity:       serious
 > >>>Priority:       medium
 > >>>Responsible:    unassigned
 > >>>State:          open
 > >>>Class:          sw-bug
 > >>>Submitter-Id:   net
 > >>>Arrival-Date:   Wed May 14 14:18:00 UTC 2003
 > >>>Closed-Date:
 > >>>Last-Modified:
 > >>>Originator:     milan.schulte@offis.de
 > >>>Release:        unknown-1.0
 > >>>Organization:
 > >>>Environment:
 > >>
 > >>>Description:
 > >>
 > >>Using GDB 5.3 from console of DDD 3.3.1 to print the content of an object 
 > >>aborts at some attribute:
 > >>
 > >>(gdb) print (*this)
 > >>$15 = (ControlEndCon [incomplete object]) {
 > >> <ControlNode> = {
 > >>   <GraphNode> = {
 > >>     <Node> = {
 > >>       <Element> = {
 > >>         <Base> = {
 > >>           _vptr.Base = 0x85c5038
 > >>         }, <No data fields>}, 
 > >>       members of Node: 
 > >>       myLocalSet = {Cannot access memory at address 0xfffffff4
 > >>(gdb)
 > >>
 > >>The attribute myLocalSet is *not* a pointer. Printing the attribute with 
 > >>the following command works:
 > >>
 > >>(gdb) print (*this).myLocalSet
 > >>$17 = (StorageUnitSet) {
 > >> <Element> = {
 > >>   <Base> = {
 > >>     _vptr.Base = 0x859b9d0
 > >>   }, <No data fields>}, 
 > >> <ComparableList<StorageUnit*>> = {
 > >>   <List<StorageUnit*>> = {
 > >>     <BasicType> = {
 > >>       _vptr.BasicType = 0x859b9d0
 > >>     }, 
 > >>     members of List<StorageUnit*>: 
 > >>     mySize = 0, 
 > >>     myIteratorCount = 0, 
 > >>     myHead = 0x0, 
 > >>     myTail = 0x0
 > >>   }, <No data fields>}, <No data fields>}
 > >>(gdb) 
 > >>
 > >>I'm using g++ (GCC) 3.3 and binutils 2.13.90.0.18 (i486-suse-linux) using 
 > >>BFD version 2.13.90.0.18
 > >>
 > >>The above works with the same source code using GCC 2.95.2, binutils 
 > >>2.9.5, GDB 5.1.1, DDD 3.3.1.
 > >>
 > >>Any hints appreciated!
 > >
 > >
 > >Could you please:
 > >  - Try a CVS snapshot of GDB
 > 
 > Snapshot 20030516 didn't work, same error.
 > 
 > [Remark: GCC was "gcc version 3.3 20030226 (prerelease) (SuSE Linux)".
 > But we have had the same problem with previous versions of GCC 3.x
 > (all of them build from GCC source distribution, as opposed to the
 > GCC 3.3 version currently used from a SuSE distribution).]
 > 
 > >and/or
 > >  - Provide a small test case for the problem
 > 
 > Here is a tiny test case:
 > (Took me 2 hours to reduce my code to get this, but we really depend on a 
 > solution
 > to allow shifting to GCC 3.x.)
 > 
 > ----------------------------- tst.cc -----
 > class A
 > {
 > };
 > 
 > class B : virtual public A
 > {
 > };
 > 
 > class C : public A
 > {
 >     protected:
 >         B myB;
 > };
 > 
 > int main()
 > {
 >     C *obj = new C();
 >     return 0;
 > }
 > ------------------------------------------
 > 
 > Compiled with:
 >  g++ -g tst.cc
 > 
 > Call to GDB:
 >  gdb a.out
 > 
 > GDB commands:
 > (gdb)  break tst.cc:18
 > (gdb)  run
 > (gdb)  print *obj
 > $8 = {
 >   <A> = {<No data fields>},
 >   members of C:
 >   myB = {Cannot access memory at address 0xfffffff4
 > (gdb)
 > 
 > 
 > Thanks in advance,
 
 Thank you very much for the testcase - it's the best we could ever have
 asked for.
 
 Your testcase showed two problems in GDB's value infrastructure
 relating to the way we handle nested objects.  Fixing them revealed
 two other related inconsistencies.
 
 I think that with these three fixes, your problem will go away.  Could
 you try this patch?  It's against current GDB CVS.  It should apply to
 earlier versions also, but earlier versions also have other problems in
 this area.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer
 
 2003-05-19  Daniel Jacobowitz  <drow@mvista.com>
 
 	* c-valprint.c (c_value_print): Add VALUE_OFFSET to the address
 	argument of val_print.
 	* cp-valprint.c (cp_print_value): Don't add the offset parameter
 	to the address argument of baseclass_offset or target_read_memory.
 	Do add it to the argument of cp_print_value_fields.
 
 Index: c-valprint.c
 ===================================================================
 RCS file: /cvs/src/src/gdb/c-valprint.c,v
 retrieving revision 1.18
 diff -u -p -r1.18 c-valprint.c
 --- c-valprint.c	25 Feb 2003 21:36:17 -0000	1.18
 +++ c-valprint.c	20 May 2003 04:07:27 -0000
 @@ -593,7 +593,8 @@ c_value_print (struct value *val, struct
        /* Otherwise, we end up at the return outside this "if" */
      }
  
 -  return val_print (type, VALUE_CONTENTS_ALL (val), VALUE_EMBEDDED_OFFSET (val),
 -		    VALUE_ADDRESS (val),
 +  return val_print (type, VALUE_CONTENTS_ALL (val),
 +		    VALUE_EMBEDDED_OFFSET (val),
 +		    VALUE_ADDRESS (val) + VALUE_OFFSET (val),
  		    stream, format, 1, 0, pretty);
  }
 Index: cp-valprint.c
 ===================================================================
 RCS file: /cvs/src/src/gdb/cp-valprint.c,v
 retrieving revision 1.20
 diff -u -p -r1.20 cp-valprint.c
 --- cp-valprint.c	14 Apr 2003 08:47:42 -0000	1.20
 +++ cp-valprint.c	20 May 2003 04:07:29 -0000
 @@ -555,7 +555,7 @@ cp_print_value (struct type *type, struc
  	{
  	  boffset = baseclass_offset (type, i,
  				      valaddr + offset,
 -				      address + offset);
 +				      address);
  	  skip = ((boffset == -1) || (boffset + offset) < 0) ? 1 : -1;
  
  	  if (BASETYPE_VIA_VIRTUAL (type, i))
 @@ -570,9 +570,10 @@ cp_print_value (struct type *type, struc
  		{
  		  /* FIXME (alloca): unsafe if baseclass is really really large. */
  		  base_valaddr = (char *) alloca (TYPE_LENGTH (baseclass));
 -		  if (target_read_memory (address + offset + boffset, base_valaddr,
 +		  if (target_read_memory (address + boffset, base_valaddr,
  					  TYPE_LENGTH (baseclass)) != 0)
  		    skip = 1;
 +		  address = address + boffset;
  		  thisoffset = 0;
  		  boffset = 0;
  		  thistype = baseclass;
 @@ -601,7 +602,8 @@ cp_print_value (struct type *type, struc
  	fprintf_filtered (stream, "<invalid address>");
        else
  	cp_print_value_fields (baseclass, thistype, base_valaddr,
 -			       thisoffset + boffset, address, stream, format,
 +			       thisoffset + boffset, address + boffset,
 +			       stream, format,
  			       recurse, pretty,
  			       ((struct type **)
  				obstack_base (&dont_print_vb_obstack)),


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