This is the mail archive of the insight@sourceware.cygnus.com mailing list for the Insight project.


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

Re: core dump


Fernando Nasser wrote:
> 
> Tom Tromey wrote:
> >
> > Insight once again got a segv while I had the watch window up.  This
> > time (as before, I think) it died when I re-ran my program (gcj).  I
> > had rebuilt the program and gdb had to reload it; I don't know whether
> > this happened or not.
> 
> 
> Despite the core happening when inside the update code for watched variables, the problem is
> unrelated to it.  There is no excuse for gdb's value_zero to dump core, but it seems that some
> variable (whatever you are whatching) had a bad formed type.  I would bet it is probably a bug in
> the gdb symbol reading or some compiler debug info malformation.
> 
> Unless someone knows of some limitation when calling value_zero().  There is nothing in the code
> that indicates that.  And it seems that it worked once, before Tom reloaded his program
> 
> Here is how Insight gets the type of a variable:
> 
>   /* To print the type, we simply create a zero value_ptr and
>      cast it to our type. We then typeprint this variable. */
>   val = value_zero (var->type, not_lval);
>   type_print (VALUE_TYPE (val), "", stb, -1);
> 
> Inside value_zero() allocate_value() is called and in its turn calls check_typedef().  The latter
> tries to recurse with TYPE_TARGET_TYPE (type), but that is not valid.  Why?  Nothing to do with
> Insight.
> 

I think that this kind of thing can also occur because re-running (and
reloading symbols) invalidates all of the variable code. The trees that
the variable object interface maintain contain LOTS of references to
transient memory which is invalidated whenever an executable is re-run
or symbols are reloaded. This is what makes it so fast compared to other
solutions. The side effect is, though, that gdbtk must be REALLY careful
about these buggers pointing to garbage because an objfile has been
reread.

I seem to recall adding something to gdbtk to catch this: whenever the
no_inferior hook is run, it should deletes all variables. Srctextwin,
watch, and locals windows should all do this... If not, you get
seemingly random crashes like this.

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com

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