From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Seitz To: Mo DeJong Cc: insight@sourceware.cygnus.com Subject: Re: Insight crash I have not seen before. Date: Thu, 27 Apr 2000 05:38:00 -0000 Message-id: <390834C3.88E681EB@firetalk.com> References: X-SW-Source: 2000-q2/msg00147.html 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 -- Why chat when you can Firetalk? Firetalk ID: Keith (10320) www.firetalk.com