This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: internal-error: insert_step_resume_breakpoint_at_sal
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 19 Jan 2005 10:45:36 +1300
- Subject: Re: internal-error: insert_step_resume_breakpoint_at_sal
- References: <16804.1142.136766.593493@farnswood.snap.net.nz><16874.17961.812024.375273@farnswood.snap.net.nz><41ED5C15.7070401@gnu.org>
> > 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
>
> ... and this sal/id look identical (true?).
Well symtab = 0x0 looks unassigned to me.
> This suggests that rather than inserting two different step-resume
> breakpoints it's inserting the same one twice (for possibly different
> reasons).
>
> Is it possible to determine exactly why the step-resume breakpoint is
> being inserted for each of these cases? If we know that the testsuite
> becomes possible, and with a testsuite a fix.
You'll probably need to give me a few clues. First time round,
stop_signal = TARGET_SIGNAL_0,
and second time,
stop_signal = TARGET_SIGNAL_IO.
Does that tell you anything?
Nick