[Bug general/3997] SIGTRAP handler gets reset when single stepping

["cmoller at redhat dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From cmoller at redhat dot com  2007-03-07 17:33 -------
Just as a bit of a blog, and as notes to myself, here's what's happening so far:

Presumably (I haven't checked yet, so it's "presumably") as a result of the
ptrace (PTRACE_SINGLESTEP, pid, 0, SIGTRAP); in the testcase,
kernel/utrace.c:utrace_signal_handler_singlestep() is called.  Something in
there (again, I haven't followed that path yet) results in a call to 

    arch/i386/kernel/traps.c:do_debug()

which calls 

    arch/i386/kernel/ptrace.c:send_sigtrap(SIGTRAP,...)

which calls 

    kernel/signal.c:force_sig_info()

which then sets 

    action->sa.sa_handler = SIG_DFL;

if the current action is blocked--the handler up to that point was correctly
pointing at the testcase handler;

A comment in kernel/signal.c reads:

/*
 * Force a signal that the process can't ignore: if necessary
 * we unblock the signal and change any SIG_IGN to SIG_DFL.
 *
 * Note: If we unblock the signal, we always reset it to SIG_DFL,
 * since we do not want to have a signal handler that was blocked
 * be invoked when user space had explicitly blocked it.
 *
 * We don't want to have recursive SIGSEGV's etc, for example.
 */

so I guess the behaviour is deliberate.

It will take me more poking to figure out what, if anything, should be done
about this.  I'm going to guess though that since PTRACE_SINGLESTEP results in
the child looking like it's been stopped by a SIGTRAP, and in the testcase a
non-SIG_DFL handler is being set by the child on SIGTRAP, there's a bit of
confusion.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3997

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.