From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Keith Seitz Cc: Mo DeJong , insight@sourceware.cygnus.com Subject: Re: Insight crash I have not seen before. Date: Thu, 27 Apr 2000 09:08:00 -0000 Message-id: <390865EE.B94AE08C@cygnus.com> References: <390834C3.88E681EB@firetalk.com> X-SW-Source: 2000-q2/msg00152.html Keith Seitz wrote: > > Mo DeJong wrote: > > > > Nevermind the last email I sent with the stack trace. I got this > > crash a couple of times and gdb never seems to core in the same > > place twice. I think the problem is actually with gdb rereading > > symbols from and applicaiton when you recompile tha app in between > > runs in the debugger (without quitting the debugger). My app > > was also dying from a call to assert(), but I am not sure if > > that made a diff. > > > > I was running on Red Hat 6.2 when I got these crashes by the way. > > This came up last week with Tom. Fernando has some state on it. What's > happening is that the variable code that gdbtk uses (which I guess gdb > is going to slowly migrate to?) hangs on to a lot of pointers to the > symbol table and obstacks. When the symbol table is re-read (and maybe > even if you just re-run the executable), all of these references are > bogus. > > We found out that a hook which is supposed to clean this up is not being > run anymore. I think this is either the clear_file or no_inferior hook. > Both the variable windows (Locals and Watch) and the SrcTextWin > (variable balloons) should be erasing any variable objects whenever the > inferior is killed/re-run or has symbols re-read. > Keith is absolutely right. We are working on a fix. I proposed a change to gdb and I will probably get it approved soon. It just does what Keith says, it makes sure the hook is run whenever this data becomes stale. The next insight snapshots won't have this problem. -- 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