From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Keith Seitz Cc: tromey@cygnus.com, Insight List , gdb-local@cygnus.com Subject: Re: core dump Date: Wed, 19 Apr 2000 13:18:00 -0000 Message-id: <38FE1461.532DE370@cygnus.com> References: <878zyaymrm.fsf@cygnus.com> <38FE0A58.FD220BF9@cygnus.com> <38FE0D0B.C4332BDA@firetalk.com> X-SW-Source: 2000-q2/msg00107.html 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