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

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

[Doug Evans]

[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.

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

[Daniel Jacobowitz]

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

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

[Doug Evans]

On Dec 12, 2007 7:27 PM, Daniel Jacobowitz <drow@false.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)) ?

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

[Daniel Jacobowitz]

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

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

[Jim Blandy]

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.

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

[Doug Evans]

On Dec 13, 2007 8:56 AM, Jim Blandy <jimb@codesourcery.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.