This is the mail archive of the
insight@sourceware.cygnus.com
mailing list for the Insight project.
Re: core dump
- To: Fernando Nasser <fnasser at cygnus dot com>
- Subject: Re: core dump
- From: Keith Seitz <kseitz at firetalk dot com>
- Date: Wed, 19 Apr 2000 12:46:19 -0700
- CC: tromey at cygnus dot com, Insight List <insight at sourceware dot cygnus dot com>, gdb-local at cygnus dot com
- Organization: Firetalk Communications, Inc
- References: <878zyaymrm.fsf@cygnus.com> <38FE0A58.FD220BF9@cygnus.com>
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