[Bug uprobes/5693] New: uprobes: Deal with signals rec'd w single-step pending

["jkenisto at us dot ibm dot com" <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.