public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: gdb@sources.redhat.com
Subject: internal-error: insert_step_resume_breakpoint_at_sal
Date: Sun, 16 Jan 2005 10:54:00 -0000	[thread overview]
Message-ID: <16874.17961.812024.375273@farnswood.snap.net.nz> (raw)
In-Reply-To: <16804.1142.136766.593493@farnswood.snap.net.nz>

Following my earlier e-mail (Wed, 24 Nov 2004 16:48:06 +1300):

 > Debugging emacs in CVS with gdb in CVS, I often get an error if I try to step
 > through the program after setting a breakpoint:
 > 
 > To reproduce:
 > 
 > gdb emacs
 > GNU gdb 6.3.50_2004-11-24-cvs
 > ...
 > (gdb) b Fsplit_window    (for example)
 > (gdb) run
 > 
 > `C-x 2' in Emacs
 > 
 > (gdb) n
 > infrun.c:2763: internal-error: insert_step_resume_breakpoint_at_sal: Assertion `step_resume_breakpoint == NULL' failed.
 > A problem internal to GDB has been detected,

infrun.c (in insert_step_resume_breakpoint_at_sal) says:

  /* There should never be more than one step-resume breakpoint per
     thread, so we should never be setting a new
     step_resume_breakpoint when one is already active.  */

However, in this case (and presumably others too) there is more than one
step-resume breakpoint. insert_step_resume_breakpoint_at_sal is called
at infrun.c:1931 and then infrun.c:1949 through handle_inferior_event:

First time:

#0  insert_step_resume_breakpoint_at_sal (sr_sal=
      {symtab = 0x0, section = 0x0, line = 0, pc = 134872212, end = 0}, sr_id=
      {stack_addr = 3221220224, code_addr = 134872206, special_addr = 0, stack_addr_p = 1, code_addr_p = 1, special_addr_p = 0}) at infrun.c:2671
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at#1  0x080fbe4f in insert_step_resume_breakpoint_at_frame (return_frame=0x0)
    at infrun.c:2699
#2  0x080fa6c3 in handle_inferior_event (ecs=0xbffff180) at infrun.c:1931
#3  0x080f9cb8 in wait_for_inferior () at infrun.c:974

Second time:

#0  internal_error (file=0x8221657 "infrun.c", line=2668, 
    string=0x81ef7a1 "%s: Assertion `%s' failed.") at utils.c:789
#1  0x080fbdda in insert_step_resume_breakpoint_at_sal (sr_sal=
      {symtab = 0x0, section = 0x0, line = 0, pc = 134872212, end = 0}, sr_id=
      {stack_addr = 3221220224, code_addr = 134872206, special_addr = 0, stack_addr_p = 1, code_addr_p = 1, special_addr_p = 0}) at infrun.c:2672
#2  0x080fbe4f in insert_step_resume_breakpoint_at_frame (return_frame=0x0)
    at infrun.c:2699
#3  0x080fa677 in handle_inferior_event (ecs=0xbffff180) at infrun.c:1949
#4  0x080f9cb8 in wait_for_inferior () at infrun.c:974


Previously GDB just issued a warning, but there never seemed to be any
harm in dropping the old step_resume_breakpoint. How about replacing:

gdb_assert (step_resume_breakpoint == NULL);

in insert_step_resume_breakpoint_at_sal with:

warning
 ("GDB bug: infrun.c (wait_for_inferior): dropping old step_resume breakpoint");

which used to be in check_for_old_step_resume_breakpoint?


Nick

  reply	other threads:[~2005-01-16 10:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-24  4:02 Nick Roberts
2005-01-16 10:54 ` Nick Roberts [this message]
2005-01-18 18:59   ` Andrew Cagney
2005-01-18 21:53     ` Nick Roberts
2005-01-19 15:55       ` Andrew Cagney
2005-01-20  0:59         ` Nick Roberts
2005-01-20 10:23           ` Dave Korn
2005-01-20 10:58             ` Nick Roberts
2005-01-20 17:07           ` Andrew Cagney
2005-01-21  2:47             ` Nick Roberts
2005-01-24 21:59               ` Andrew Cagney
2005-01-26 10:19                 ` Nick Roberts
2005-01-26 16:26                   ` Andrew Cagney
2005-01-26 20:48                     ` Nick Roberts
2005-01-26 21:39                       ` Andrew Cagney
2005-01-27  1:02                         ` Nick Roberts
2005-02-06  7:16                           ` Andrew Cagney
2005-02-06  7:26                             ` Andrew Cagney
2005-02-06 20:11                             ` Nick Roberts
2005-02-08 16:57                               ` Andrew Cagney

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=16874.17961.812024.375273@farnswood.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb@sources.redhat.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).