[Bug uprobes/5079] New: runtime/uprobes: stap module exit w/ outstanding uretprobe_instances

["jkenisto at us dot ibm dot com" <sourceware-bugzilla@sourceware.org>]

Here's a situation where including the uprobes code as part of the
SystemTap-generated module messes us up.

Execute a program like this:
#include <unistd.h>
#include <stdio.h>

int sleeper()    /* set the retprobe here */
{
         sleep(1);
         return 1;
}

main()
{
         int ret;
         for (;;){
                 ret = sleeper();
                 printf("sleeper returns %d\n",ret);
         }
}
and then probe it with a stap module such as this:
probe begin {
        log("Probing...")
}
probe process($1).statement($2).absolute.return
{
        log (pp())
}
with a command such as
# stap sleeper.stp <pid> <sleeper_vaddr>

If you CTRL-C out of stap while sleeper() is running, you'll get an oops.

That's because unregister_uretprobe(), called by the module's cleanup function,
doesn't wait for the uretprobed function to return.  (It could be a LONG wait,
after all.)  Instead, it leaves the uprobe_process (and utrace_attached_engine)
in place until sleeper() returns and hits the breakpoint at the uretprobe
trampoline; uprobes's report_signal callback should then clean up.  (This is
pretty much how kretprobes works, too.)  Unfortunately, by that time, the
uprobes code no longer exists -- it disappeared with the module -- so utrace
calls a nonexistent callbck.

We could work around this on i386 and x86_64 by remembering the location, on the
stack, of the return address, and stuffing the real return address back into the
stack as part of unregister_uretprobe().  (That's how kretprobes was originally
implemented.)  For the other architectures, though, this won't work, I'm told.

-- 
           Summary: runtime/uprobes: stap module exit w/ outstanding
                    uretprobe_instances
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: critical
          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=5079

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