From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17549 invoked by alias); 7 Mar 2007 17:34:07 -0000 Received: (qmail 17456 invoked by uid 48); 7 Mar 2007 17:33:53 -0000 Date: Wed, 07 Mar 2007 17:34:00 -0000 Message-ID: <20070307173353.17455.qmail@sourceware.org> From: "cmoller at redhat dot com" To: frysk-bugzilla@sourceware.org In-Reply-To: <20070207161918.3997.mark@klomp.org> References: <20070207161918.3997.mark@klomp.org> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug general/3997] SIGTRAP handler gets reset when single stepping X-Bugzilla-Reason: AssignedTo Mailing-List: contact frysk-bugzilla-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: frysk-bugzilla-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00574.txt.bz2 List-Id: ------- 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.