protection from dangling pointers in dwarf info when .so's go away

[target = i386-linux]

Hi. I'm debugging a gdb segv where a .so provides
TYPE_VPTR_{BASETYPE,FIELDNO} while gdb is evaluating an
expression.

e.g.

$ gdb my-prog
(gdb) b foo
(gdb) run
Breakpoint 1 hit
(gdb) p myclass->bar ()

At this point the "struct type" for myclass has
type->main_type->vptr_basetype pointing into the
obstack for the .so.

If I run the program again and do the same thing, i.e.

(gdb) run
Start from the beginning?  y
Breakpoint 1 hit
(gdb) p myclass->bar ()

--> segv because when the program was rerun all the
obstacks for the
.so's got freed (by objfile_purge_solibs) leaving a bogus
value in
vptr_basetype.

How is this supposed to work?

Is it the case that vptr_basetype for myclass should never
have gotten
assigned a value pointing into a .so (or any other obstack)?
 Or is
gdb supposed to have cleaned up after itself when the .so
data got
freed?  Or something else?  Any guidance on where the fix
should go is
appreciated.  I suppose an easy solution is to toss out all
info, not
just for .so's, though that will slow down re-runs.

Thanks.

On Wed, Dec 12, 2007 at 05:57:58PM -0800, Doug Evans wrote:
> Is it the case that vptr_basetype for myclass should
never have gotten
> assigned a value pointing into a .so (or any other
obstack)?

Sounds likely to me, but may not be practical.

> Or is
> gdb supposed to have cleaned up after itself when the
.so data got
> freed?

We do this for user variables when their objfile goes away,
by
recursively copying their type.  We don't walk types from
other
objfiles looking for pointers, so there really shouldn't be
any.

> Or something else?  Any guidance on where the fix
should go is
> appreciated.  I suppose an easy solution is to toss out
all info, not
> just for .so's, though that will slow down re-runs.

No, that's impossible.  Remember dlopen and dlclose.

-- 
Daniel Jacobowitz
CodeSourcery

On Dec 12, 2007 7:27 PM, Daniel Jacobowitz <drowfalse.org> wrote:
> On Wed, Dec 12, 2007 at 05:57:58PM -0800, Doug Evans
wrote:
> > Is it the case that vptr_basetype for myclass
should never have gotten
> > assigned a value pointing into a .so (or any other
obstack)?
>
> Sounds likely to me, but may not be practical.
>
> > Or is
> > gdb supposed to have cleaned up after itself when
the .so data got
> > freed?
>
> We do this for user variables when their objfile goes
away, by
> recursively copying their type.  We don't walk types
from other
> objfiles looking for pointers, so there really
shouldn't be any.
>
> > Or something else?  Any guidance on where the fix
should go is
> > appreciated.  I suppose an easy solution is to
toss out all info, not
> > just for .so's, though that will slow down
re-runs.
>
> No, that's impossible.  Remember dlopen and dlclose.

Righto, and thanks.

It seems like check_typedef is aware of the issue:

    /* [...] We can't create pointers between
             types allocated to different objfiles, since
they may
             have different lifetimes.  [...] */

but fill_in_vptr_fieldno is not:

void
fill_in_vptr_fieldno (struct type *type)
{
  CHECK_TYPEDEF (type);

  if (TYPE_VPTR_FIELDNO (type) < 0)
    {
      int i;

      /* We must start at zero in case the first (and only)
baseclass
         is virtual (and hence we cannot share the table
pointer).  */
      for (i = 0; i < TYPE_N_BASECLASSES (type); i++)
        {
          struct type *baseclass = check_typedef
(TYPE_BASECLASS (type,
                                                            
     i));
          fill_in_vptr_fieldno (baseclass);
          if (TYPE_VPTR_FIELDNO (baseclass) >= 0)
            {
              TYPE_VPTR_FIELDNO (type) = TYPE_VPTR_FIELDNO
(baseclass);
              TYPE_VPTR_BASETYPE (type) = TYPE_VPTR_BASETYPE
(baseclass);
              break;
            }
        }
    }
}

What happens if TYPE_OBJFILE (type) != TYPE_OBJFILE
(TYPE_VPTR_BASETYPE (baseclass)) ?

On Thu, Dec 13, 2007 at 12:16:36AM -0800, Doug Evans wrote:
> What happens if TYPE_OBJFILE (type) != TYPE_OBJFILE
> (TYPE_VPTR_BASETYPE (baseclass)) ?

Precisely what you saw, but how does this happen?  The
baseclass links
should normally point through to other types in the same
objfile.

I'm guessing that there was inadequate debug info for a base
class,
leading GDB to do name resolution into a shared library with
better
debug info (probably because it defined the class's key
method)?

-- 
Daniel Jacobowitz
CodeSourcery

Daniel Jacobowitz <drow at false.org> writes:
> On Thu, Dec 13, 2007 at 12:16:36AM -0800, Doug Evans
wrote:
>> What happens if TYPE_OBJFILE (type) !=
TYPE_OBJFILE
>> (TYPE_VPTR_BASETYPE (baseclass)) ?
>
> Precisely what you saw, but how does this happen?  The
baseclass links
> should normally point through to other types in the
same objfile.
>
> I'm guessing that there was inadequate debug info for a
base class,
> leading GDB to do name resolution into a shared library
with better
> debug info (probably because it defined the class's key
method)?

If I remember right, the way we usually handle this is by
leaving the
types from the main executable 'incomplete', as if it had
just seen
'struct foo' but no definition for it.  When we need the
full
definition of 'struct foo', we look it up by name, find it
whereever
it happens to be available, and use it there.  So we do an
extra name
lookup, because that allows the reference to break naturally
when
objfiles are freed.

But there shouldn't be pointers between objfiles, for the
reasons
stated.

On Dec 13, 2007 8:56 AM, Jim Blandy <jimbcodesourcery.com> wrote:
>
>
> Daniel Jacobowitz <drow at false.org> writes:
> > On Thu, Dec 13, 2007 at 12:16:36AM -0800, Doug
Evans wrote:
> >> What happens if TYPE_OBJFILE (type) !=
TYPE_OBJFILE
> >> (TYPE_VPTR_BASETYPE (baseclass)) ?
> >
> > Precisely what you saw, but how does this happen? 
The baseclass links
> > should normally point through to other types in
the same objfile.
> >
> > I'm guessing that there was inadequate debug info
for a base class,
> > leading GDB to do name resolution into a shared
library with better
> > debug info (probably because it defined the
class's key method)?
>
> If I remember right, the way we usually handle this is
by leaving the
> types from the main executable 'incomplete', as if it
had just seen
> 'struct foo' but no definition for it.  When we need
the full
> definition of 'struct foo', we look it up by name, find
it whereever
> it happens to be available, and use it there.  So we do
an extra name
> lookup, because that allows the reference to break
naturally when
> objfiles are freed.
>
> But there shouldn't be pointers between objfiles, for
the reasons
> stated.

It turns out all that's needed is for the baseclass in
question live in a .so.
I filed 2384, and will submit a proposed patch shortly.