From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-7334-listarch-systemtap=sources.redhat.com@sourceware.org>
Received: (qmail 24733 invoked by alias); 28 Sep 2007 23:35:03 -0000
Received: (qmail 24632 invoked by uid 48); 28 Sep 2007 23:34:54 -0000
Date: Sun, 30 Sep 2007 19:26:00 -0000
From: "jkenisto at us dot ibm dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sources.redhat.com
Message-ID: <20070928233453.5079.jkenisto@us.ibm.com>
Reply-To: sourceware-bugzilla@sourceware.org
Subject: [Bug uprobes/5079] New: runtime/uprobes: stap module exit w/ outstanding uretprobe_instances
X-Bugzilla-Reason: AssignedTo
Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <systemtap.sourceware.org>
List-Subscribe: <mailto:systemtap-subscribe@sourceware.org>
List-Post: <mailto:systemtap@sourceware.org>
List-Help: <mailto:systemtap-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-owner@sourceware.org
X-SW-Source: 2007-q3/txt/msg00740.txt.bz2

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.