[Bug dyninst/15049] New: stapdyn mishandling interrupts

[Bug dyninst/15049] New: stapdyn mishandling interrupts

[dsmith at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15049

             Bug #: 15049
           Summary: stapdyn mishandling interrupts
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dyninst
        AssignedTo: systemtap@sourceware.org
        ReportedBy: dsmith@redhat.com
    Classification: Unclassified


Here's the linux runtime:

====
# stap -e 'probe end { printf("*** exiting ***\n"); exit() }'
^C*** exiting ***
====

Here's the dyninst runtime:

====
stap --runtime=dyninst -e 'probe end { printf("*** exiting ***\n"); exit() }'
*** exiting ***
====

In the above case, stapdyn exits immediately. Let's give stapdyn something to
run so it will hang around:

====
# stap --runtime=dyninst -e 'probe end { printf("*** exiting ***\n"); exit() }'
-c cat
^Cstapdyn: WARNING: Multiple interrupts received, exiting...
*** exiting ***
WARNING: /usr/local/bin/stapdyn exited with status: 1
Pass 5: run failed.  Try again with another '--vp 00001' option.
====

Notice that even though I only interrupted stapdyn once, it complained of
multiple interrupts and exited with a non-zero exit value (which might be
related to bug #15029).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15049] stapdyn mishandling interrupts

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15049

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #1 from Josh Stone <jistone at redhat dot com> 2013-01-22 17:12:42 UTC ---
True, this needs more work, but bug 14665 is still open.

(In reply to comment #0)
> In the above case, stapdyn exits immediately. Let's give stapdyn something to
> run so it will hang around:

Yes, that should get fixed too.  That's part of why I was trying to get the
dyninst notification FD working (currently #if 0 in mutator::run) so we could
have a proper wait loop and break out in different ways, but it was failing for
me.

> Notice that even though I only interrupted stapdyn once, it complained of
> multiple interrupts and exited with a non-zero exit value (which might be
> related to bug #15029).

I was trying to be clever and give it a way out when truly stuck.  Like:
- 1st signal: pass the signal to the app and try to wait for it.
- 2nd signal: forget about the app, it's stuck, so just cleanup and quit.
- more signals: we must be stuck too, _exit().

But what happens here is the terminal CTRL-C gets sent to the whole process
group, including stap and stapdyn.  Then stap sends a signal to stapdyn too, so
now it has seen two.

So, this probably needs to be more clever.  Or less clever.  Suggestions
welcome.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15049] stapdyn mishandling interrupts

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15049

--- Comment #2 from Josh Stone <jistone at redhat dot com> ---
Commits 6d27dcff and 63f4648b have improved the situation somewhat.  The
no-command case will now wait around for a signal or script exit(), just as
kernel mode does.  With a command, it should be a little better, but there's an
issue that Dyninst is squashing SIGINTs to mutatees.

https://lists.cs.wisc.edu/archive/dyninst-api/2013/msg00113.shtml

I've tested a patch so that PCEventHandler::shouldStopForSignal() doesn't count
SIGINT, and that seems to be much better.  I'll send that with justification to
dyninst-api and see what they think, and then this bug may be resolved.

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

[Bug dyninst/15049] stapdyn mishandling interrupts

[jistone at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15049

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Josh Stone <jistone at redhat dot com> ---
(In reply to Josh Stone from comment #2)
> I've tested a patch so that PCEventHandler::shouldStopForSignal() doesn't
> count SIGINT, and that seems to be much better.  I'll send that with
> justification to dyninst-api and see what they think, and then this bug may
> be resolved.

This patch went into dyninst as commit d8b45719a9d1, and is in release 8.2.0.

With that, I think stapdyn signal handling is in pretty good shape.

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