[rfa] allocate_objfile(NULL, 0)

[rfa] allocate_objfile(NULL, 0)

[David Carlton]

The function allocate_objfile takes some care to return a useful
objfile if its first argument (the bfd) is NULL.  But it doesn't set
objfile->name in that case; there is code in GDB that loops over all
the objfiles and examines their names, which breaks in this case.
(See, for example, symbol_add_stub.)

I ran into this problem when imitating the dynamics objfile in
jv-lang.c.  So I'm pretty sure that, currently, if anybody tries to
debug Java code that requires that objfile to exist, GDB will seg
fault.

The enclosed patch modifies allocate_objfile to set the name to
"<<anonymous objfile>>" in that situation.  It removes the seg fault
that I saw.  I ran the test suite on i686-pc-linux-gnu/GCC 3.1/DWARF-2
and saw no new regressions.

Is this patch okay?  I don't know offhand who the appropriate
maintainer is.

David Carlton
carlton@math.stanford.edu

2003-01-10  David Carlton  <carlton@math.stanford.edu>

	* objfiles.c (allocate_objfile): Always set name.

Index: objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.22
diff -u -p -r1.22 objfiles.c
--- objfiles.c	29 Jul 2002 22:55:26 -0000	1.22
+++ objfiles.c	10 Jan 2003 23:31:56 -0000
@@ -305,6 +305,10 @@ allocate_objfile (bfd *abfd, int flags)
 		 objfile->name, bfd_errmsg (bfd_get_error ()));
 	}
     }
+  else
+    {
+      objfile->name = "<<anonymous objfile>>";
+    }
 
   /* Initialize the section indexes for this objfile, so that we can
      later detect if they are used w/o being properly assigned to. */

Re: [rfa] allocate_objfile(NULL, 0)

[Elena Zannoni]

David Carlton writes:
 > The function allocate_objfile takes some care to return a useful
 > objfile if its first argument (the bfd) is NULL.  But it doesn't set
 > objfile->name in that case; there is code in GDB that loops over all
 > the objfiles and examines their names, which breaks in this case.
 > (See, for example, symbol_add_stub.)
 > 
 > I ran into this problem when imitating the dynamics objfile in
 > jv-lang.c.  So I'm pretty sure that, currently, if anybody tries to
 > debug Java code that requires that objfile to exist, GDB will seg
 > fault.
 > 

Can you expand a bit? Would it be possible to create a test case?

 > The enclosed patch modifies allocate_objfile to set the name to
 > "<<anonymous objfile>>" in that situation.  It removes the seg fault
 > that I saw.  I ran the test suite on i686-pc-linux-gnu/GCC 3.1/DWARF-2
 > and saw no new regressions.
 > 
 > Is this patch okay?  I don't know offhand who the appropriate
 > maintainer is.
 > 

I don't know about the '<<' '>>' usage. I wonder if gdb already
has some other cases like this one. Maybe 'nameless'?

 > David Carlton
 > carlton@math.stanford.edu
 > 
 > 2003-01-10  David Carlton  <carlton@math.stanford.edu>
 > 
 > 	* objfiles.c (allocate_objfile): Always set name.

You are missing the copyright year.

 > 
 > Index: objfiles.c 
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/objfiles.c,v
 > retrieving revision 1.22
 > diff -u -p -r1.22 objfiles.c
 > --- objfiles.c	29 Jul 2002 22:55:26 -0000	1.22
 > +++ objfiles.c	10 Jan 2003 23:31:56 -0000
 > @@ -305,6 +305,10 @@ allocate_objfile (bfd *abfd, int flags)
 >  		 objfile->name, bfd_errmsg (bfd_get_error ()));
 >  	}
 >      }
 > +  else
 > +    {
 > +      objfile->name = "<<anonymous objfile>>";
 > +    }
 >  
 >    /* Initialize the section indexes for this objfile, so that we can
 >       later detect if they are used w/o being properly assigned to. */

Re: [rfa] allocate_objfile(NULL, 0)

[David Carlton]

On Fri, 10 Jan 2003 19:05:00 -0500, Elena Zannoni <ezannoni@redhat.com> said:
> David Carlton writes:

>> The function allocate_objfile takes some care to return a useful
>> objfile if its first argument (the bfd) is NULL.  But it doesn't set
>> objfile-> name in that case; there is code in GDB that loops over
>> all the objfiles and examines their names, which breaks in this
>> case.  (See, for example, symbol_add_stub.)

>> I ran into this problem when imitating the dynamics objfile in
>> jv-lang.c.  So I'm pretty sure that, currently, if anybody tries to
>> debug Java code that requires that objfile to exist, GDB will seg
>> fault.

> Can you expand a bit? Would it be possible to create a test case?

I'm no Java expert, but here's the situation as I understand it.  When
evaluating Java code, sometimes you have to generate new Java classes
in an unpredictable manner.  When this happens, there isn't any file
around to get debug info from.  So jv-lang.c generates a symbol for
those classes; it has to store it in a global block somewhere so the
symbol gets searched, so it creates an objfile that isn't associated
to any physical file, just for the purpose of storing a symtab in it
to put these symbols.  This is the code in the first part of jv-lang.c

When I tried to imitate this on a branch for my own nefarious
purposes, GDB started to segfault, and this was the reason.  I assume
that it could also segfault in the Java case, at least if you could
convince symbol_add_stub to run after one of these dynamic classes was
generated.  Alas, I don't know enough Java to be able to create a test
case.

>> The enclosed patch modifies allocate_objfile to set the name to
>> "<<anonymous objfile>>" in that situation.  It removes the seg fault
>> that I saw.  I ran the test suite on i686-pc-linux-gnu/GCC 3.1/DWARF-2
>> and saw no new regressions.
>> 
>> Is this patch okay?  I don't know offhand who the appropriate
>> maintainer is.

> I don't know about the '<<' '>>' usage. I wonder if gdb already
> has some other cases like this one. Maybe 'nameless'?

My reasoning behind the <<>> is that I wanted to pick a string that
was unlikely to look like an actual filename.  That way, people
wouldn't accidentally get an anonymous objfile when they were looking
for an objfile associated to an actual file.  But I'm certainly
flexible; whatever you think is best.

>> David Carlton
>> carlton@math.stanford.edu
>> 
>> 2003-01-10  David Carlton  <carlton@math.stanford.edu>
>> 
>> * objfiles.c (allocate_objfile): Always set name.

> You are missing the copyright year.

Whoops!  Good catch, thanks.

David Carlton
carlton@math.stanford.edu

Re: [rfa] allocate_objfile(NULL, 0)

[Tom Tromey]

>>>>> "David" == David Carlton <carlton@math.stanford.edu> writes:

David> I'm no Java expert, but here's the situation as I understand
David> it.  When evaluating Java code, sometimes you have to generate
David> new Java classes in an unpredictable manner.

David> Alas, I don't know enough Java to be able to create a test
David> case.

I don't know very much about this part of gdb.  However, I can say
that in libgcj we create classes on the fly to represent arrays.  Even
the simplest Java program will create at least one such array (for
String[]):

public class t
{
  public static void main(String[] args)
  {
     System.out.println(args.length);
  }
}

Then compile with:

gcj --main=t -o t t.java


There is at least one longstanding gdb SEGV that happens when trying
to re-run a Java executable.  This happens in most, but not every, gdb
session.

Unfortunately I can't try your patch in the near future.

Tom

Re: [rfa] allocate_objfile(NULL, 0)

[Elena Zannoni]

Tom Tromey writes:
 > >>>>> "David" == David Carlton <carlton@math.stanford.edu> writes:
 > 
 > David> I'm no Java expert, but here's the situation as I understand
 > David> it.  When evaluating Java code, sometimes you have to generate
 > David> new Java classes in an unpredictable manner.
 > 
 > David> Alas, I don't know enough Java to be able to create a test
 > David> case.
 > 
 > I don't know very much about this part of gdb.  However, I can say
 > that in libgcj we create classes on the fly to represent arrays.  Even
 > the simplest Java program will create at least one such array (for
 > String[]):
 > 
 > public class t
 > {
 >   public static void main(String[] args)
 >   {
 >      System.out.println(args.length);
 >   }
 > }
 > 
 > Then compile with:
 > 
 > gcj --main=t -o t t.java
 > 
 > 
 > There is at least one longstanding gdb SEGV that happens when trying
 > to re-run a Java executable.  This happens in most, but not every, gdb
 > session.
 > 
 > Unfortunately I can't try your patch in the near future.
 > 
 > Tom

David, Tom, could a little gdb test be created and put in gdb.java?

elena

Re: [rfa] allocate_objfile(NULL, 0)

[Tom Tromey]

>>>>> "Elena" == Elena Zannoni <ezannoni@redhat.com> writes:

Elena> David, Tom, could a little gdb test be created and put in gdb.java?

David said he couldn't reproduce the problem using this code.

I don't have a simple recipe for the "re-run segv".
Any serious java debugging with gdb will show it, but that doesn't
make it easy to write a test case.

Tom

Re: [rfa] allocate_objfile(NULL, 0)

[Elena Zannoni]

David Carlton writes:
 > On Fri, 10 Jan 2003 19:05:00 -0500, Elena Zannoni <ezannoni@redhat.com> said:
 > > David Carlton writes:
 > 
 > >> The function allocate_objfile takes some care to return a useful
 > >> objfile if its first argument (the bfd) is NULL.  But it doesn't set
 > >> objfile-> name in that case; there is code in GDB that loops over
 > >> all the objfiles and examines their names, which breaks in this
 > >> case.  (See, for example, symbol_add_stub.)
 > 
 > >> I ran into this problem when imitating the dynamics objfile in
 > >> jv-lang.c.  So I'm pretty sure that, currently, if anybody tries to
 > >> debug Java code that requires that objfile to exist, GDB will seg
 > >> fault.
 > 
 > > Can you expand a bit? Would it be possible to create a test case?
 > 
 > I'm no Java expert, but here's the situation as I understand it.  When
 > evaluating Java code, sometimes you have to generate new Java classes
 > in an unpredictable manner.  When this happens, there isn't any file
 > around to get debug info from.  So jv-lang.c generates a symbol for
 > those classes; it has to store it in a global block somewhere so the
 > symbol gets searched, so it creates an objfile that isn't associated
 > to any physical file, just for the purpose of storing a symtab in it
 > to put these symbols.  This is the code in the first part of jv-lang.c
 > 
 > When I tried to imitate this on a branch for my own nefarious
 > purposes, GDB started to segfault, and this was the reason.  I assume
 > that it could also segfault in the Java case, at least if you could
 > convince symbol_add_stub to run after one of these dynamic classes was
 > generated.  Alas, I don't know enough Java to be able to create a test
 > case.
 > 
 > >> The enclosed patch modifies allocate_objfile to set the name to
 > >> "<<anonymous objfile>>" in that situation.  It removes the seg fault
 > >> that I saw.  I ran the test suite on i686-pc-linux-gnu/GCC 3.1/DWARF-2
 > >> and saw no new regressions.
 > >> 
 > >> Is this patch okay?  I don't know offhand who the appropriate
 > >> maintainer is.
 > 
 > > I don't know about the '<<' '>>' usage. I wonder if gdb already
 > > has some other cases like this one. Maybe 'nameless'?
 > 
 > My reasoning behind the <<>> is that I wanted to pick a string that
 > was unlikely to look like an actual filename.  That way, people
 > wouldn't accidentally get an anonymous objfile when they were looking
 > for an objfile associated to an actual file.  But I'm certainly
 > flexible; whatever you think is best.

I cannot come up with anything better at the moment, so OK, but...
could you add comments? Kind of summarize your mail and Tom's mail.

elena


 > 
 > >> David Carlton
 > >> carlton@math.stanford.edu
 > >> 
 > >> 2003-01-10  David Carlton  <carlton@math.stanford.edu>
 > >> 
 > >> * objfiles.c (allocate_objfile): Always set name.
 > 
 > > You are missing the copyright year.
 > 
 > Whoops!  Good catch, thanks.
 > 
 > David Carlton
 > carlton@math.stanford.edu

Re: [rfa] allocate_objfile(NULL, 0)

[David Carlton]

On Tue, 4 Feb 2003 13:08:53 -0500, Elena Zannoni <ezannoni@redhat.com> said:

> I cannot come up with anything better at the moment, so OK, but...
> could you add comments? Kind of summarize your mail and Tom's mail.

Okay, I've added comments at the beginning of allocate_objfile and at
its caller in the Java code mentioning the situation.  I've committed
the attached; I also committed it to 5.3, on the off chance that 5.3.1
ever happens.

David Carlton
carlton@math.stanford.edu

2003-02-04  David Carlton  <carlton@math.stanford.edu>

	* objfiles.c (allocate_objfile): Always set name.  Add comment at
	start of function.
	* jv-lang.c (get_dynamics_objfile): Add comment.

Index: objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.26
diff -u -p -r1.26 objfiles.c
--- objfiles.c	4 Feb 2003 18:07:01 -0000	1.26
+++ objfiles.c	4 Feb 2003 21:52:59 -0000
@@ -150,6 +150,15 @@ build_objfile_section_table (struct objf
    OBJF_SHARED are simply copied through to the new objfile flags
    member. */
 
+/* NOTE: carlton/2003-02-04: This function is called with args NULL, 0
+   by jv-lang.c, to create an artificial objfile used to hold
+   information about dynamically-loaded Java classes.  Unfortunately,
+   that branch of this function doesn't get tested very frequently, so
+   it's prone to breakage.  (E.g. at one time the name was set to NULL
+   in that situation, which broke a loop over all names in the dynamic
+   library loader.)  If you change this function, please try to leave
+   things in a consistent state even if abfd is NULL.  */
+
 struct objfile *
 allocate_objfile (bfd *abfd, int flags)
 {
@@ -312,6 +321,10 @@ allocate_objfile (bfd *abfd, int flags)
 	  error ("Can't find the file sections in `%s': %s",
 		 objfile->name, bfd_errmsg (bfd_get_error ()));
 	}
+    }
+  else
+    {
+      objfile->name = "<<anonymous objfile>>";
     }
 
   /* Initialize the section indexes for this objfile, so that we can
Index: jv-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/jv-lang.c,v
retrieving revision 1.12
diff -u -p -r1.12 jv-lang.c
--- jv-lang.c	11 Jul 2002 20:46:19 -0000	1.12
+++ jv-lang.c	4 Feb 2003 21:53:04 -0000
@@ -68,6 +68,12 @@ static struct objfile *dynamics_objfile 
 
 static struct type *java_link_class_type (struct type *, struct value *);
 
+/* FIXME: carlton/2003-02-04: This is the main or only caller of
+   allocate_objfile with first argument NULL; as a result, this code
+   breaks every so often.  Somebody should write a test case that
+   exercises GDB in various ways (e.g. something involving loading a
+   dynamic library) after this code has been called.  */
+
 static struct objfile *
 get_dynamics_objfile (void)
 {