Re: internal-error: insert_step_resume_breakpoint_at_sal

[Andrew Cagney <cagney at gnu dot org>]

Nick Roberts wrote:
>  > > 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.

More likely not-found, what's at that address?

>  > 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?

It makes me wonder if the inferior got an I/O signal and GDB to trying 
to skip that simultaneous to something else.  That, however, is idle 
speculation on my part.  It might be able to test this by modifying 
gdb.base/sigstep.c to schedule two signals instead of one.

Can you capture the output from "set debug infrun 1"?  It should help.

Andrew