This is the mail archive of the gdb@sourceware.org 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]

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.


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