This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug uprobes/5693] New: uprobes: Deal with signals rec'd w single-step pending
- From: "jkenisto at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 30 Jan 2008 00:30:09 -0000
- Subject: [Bug uprobes/5693] New: uprobes: Deal with signals rec'd w single-step pending
- Reply-to: sourceware-bugzilla at sourceware dot org
This bug is most easily seen when probing an app that was compiled with
profiling enabled (gcc -p). -p causes the process to receive SIGPROF signals,
apparently intended to be handled by a SIGPROF handler function that's linked
with the program. If the signal arrives when the receiving thread is about to
single-step at a probepoint, there's trouble.
Just before calling the handler, utrace disables single-stepping for the thread
and calls uprobe_report_signal() with action=UTRACE_SIGNAL_HANDLER and
info=NULL. (utrace is behaving reasonably here, or at least as documented, as
far as I can tell.) First of all, uprobes needs to check for info=NULL before
dereferencing info.
But that's not enough. I think by the time we get called with
action=UTRACE_SIGNAL_HANDLER, it's too late. (How and when would we re-enable
single-stepping? In particular, it can't be done with the return value from
uprobe_report_signal() in this special case.) I've been looking for ways to
delay calling the signal handler until after the thread has single-stepped.
Before doing the UTRACE_SIGNAL_HANDLER bit, utrace calls uprobes_report_signal()
with action=UTRACE_ACTION_RESUME (sic) to indicate that it's about to call a
signal handler. When that happens, if a single-step is pending, I save a copy
of the siginfo_t and the k_sigaction (if any), and return UTRACE_ACTION_HIDE |
UTRACE_SIGNAL_IGN | UTRACE_ACTION_NEWSTATE to suppress the call to the signal
handler. This heads off the UTRACE_SIGNAL_HANDLER event. Then, after
single-stepping the probed instruction, I try to re-introduce the signal. So
far I've tried utrace_inject_signal(), send_sig_info(), and send_sig(). The
process always dies right away -- variously with an exit code of SIGSEGV,
SIGTRAP, SIGILL, or even 0. In fact, it dies even if I don't re-introduce the
signal at all. Note that if it's a multithreaded app, the first thread to die
may or may not be the thread that received the signal in the first place.
--
Summary: uprobes: Deal with signals rec'd w single-step pending
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: uprobes
AssignedTo: systemtap at sources dot redhat dot com
ReportedBy: jkenisto at us dot ibm dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=5693
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.