This is the mail archive of the
insight@sourceware.cygnus.com
mailing list for the Insight project.
Re: core dump
- To: Keith Seitz <kseitz at firetalk dot com>
- Subject: Re: core dump
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Wed, 19 Apr 2000 20:17:37 +0000
- CC: tromey at cygnus dot com, Insight List <insight at sourceware dot cygnus dot com>, gdb-local at cygnus dot com
- Organization: Cygnus Solutions (a Red Hat company) - Toronto
- References: <878zyaymrm.fsf@cygnus.com> <38FE0A58.FD220BF9@cygnus.com> <38FE0D0B.C4332BDA@firetalk.com>
Keith Seitz wrote:
>
> 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.
>
This makes sense. But no_inferior (the callback you are refering to) is called and deletes all
variable objects.
So, the code in VariableWin and WatchedWin is doing the right thing.
Unless the hook is not being run...
Tom, can you invoke Insight with the debug window and see if "deleteTree" is printed in there when
you reload your file?
Thanks.
--
Fernando Nasser
Cygnus Solutions (a Red Hat company) E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299