public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Fernando Nasser <fnasser@cygnus.com>
To: Keith Seitz <kseitz@firetalk.com>
Cc: Mo DeJong <mdejong@cygnus.com>, insight@sourceware.cygnus.com
Subject: Re: Insight crash I have not seen before.
Date: Thu, 27 Apr 2000 09:08:00 -0000	[thread overview]
Message-ID: <390865EE.B94AE08C@cygnus.com> (raw)
In-Reply-To: <390834C3.88E681EB@firetalk.com>

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

      reply	other threads:[~2000-04-27  9:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-27  0:17 Mo DeJong
2000-04-27  1:35 ` Mo DeJong
2000-04-27  5:38   ` Keith Seitz
2000-04-27  9:08     ` Fernando Nasser [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=390865EE.B94AE08C@cygnus.com \
    --to=fnasser@cygnus.com \
    --cc=insight@sourceware.cygnus.com \
    --cc=kseitz@firetalk.com \
    --cc=mdejong@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).