This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
breakpoints/1738: Single stepping and signals don't interact well
- From: dan at debian dot org
- To: gdb-gnats at sources dot redhat dot com
- Date: 8 Aug 2004 23:02:37 -0000
- Subject: breakpoints/1738: Single stepping and signals don't interact well
- Reply-to: 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: