breakpoints/1738: Single stepping and signals don't interact well

[dan at debian dot org]

>Number:         1738
>Category:       breakpoints
>Synopsis:       Single stepping and signals don't interact well
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 08 23:08:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     dan@debian.org
>Release:        2004-04-08
>Organization:
>Environment:
i686-pc-linux-gnu
>Description:
There are two fails in signals.exp on this platform, and several others.  They used to be xfailed.  They are:
(gdb) FAIL: gdb.base/signals.exp: continue to handler for 3rd alarm call (the program exited)
(gdb) FAIL: gdb.base/signals.exp: backtrace for 3rd alarm

The symptom is that we say "continue" and the inferior exits instead of hitting a breakpoint.  I analyzed a similar problem instead - if we say "next" the inferior also exits.  This is slightly clearer.

We're stopped in func2, and while we're stopped the inferior receives a SIGALRM.  We attempt to single-step with breakpoints removed, but receive SIGALRM instead of SIGTRAP.  At this point the PC has not changed.  We go to this bit of infrun.c:

1968              /* The inferior is about to take a signal that will take it
1969                 out of the single step range.  Set a breakpoint at the
1970                 current PC (which is presumably where the signal handler
1971                 will eventually return) and then allow the inferior to
1972                 run free.
1973
1974                 Note that this is only needed for a signal delivered
1975                 while in the single-step range.  Nested signals aren't a
1976                 problem as they eventually all return.  */

This leads to creating a breakpoint and calling keep_going.  But breakpoints are not inserted so the new breakpoint is not inserted.  keep_going causes us to single-step again,
but deliver the SIGALRM.  Breakpoints are removed, so we stop after handler has run [oops].  At this point trap_expected is set (it was set in proceed because we were stepping over a breakpoint).  Normally we would see that we have stepped out of the stepping range and stop... but step_resume_breakpoint is set.  This triggers:

  if (step_resume_breakpoint)
    { 
      /* Having a step-resume breakpoint overrides anything
         else having to do with stepping commands until
         that breakpoint is reached.  */
      keep_going (ecs);
      return;
    }

We consume the SIGTRAP after ++count, and continue.  The program exits.

currently_stepping normally returns 0 if a step_resume_breakpoint is set, but does not if trap_expected.  This may be the bug.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: