This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/10575] occasional stapio hangs for -c CMD
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 31 Aug 2009 17:40:33 -0000
- Subject: [Bug runtime/10575] occasional stapio hangs for -c CMD
- References: <20090829202719.10575.fche@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jistone at redhat dot com 2009-08-31 17:40 -------
(In reply to comment #1)
> In one scenario, the initial SIGUSR1 sent to the target_cmd-executing
> stapio process appears to be lost (either not received, or sent before
> the child program was listening for it, or perhaps not sent at all?!).
Do your scripts have lots of output? It could be related to #10189, where
STP_START gets lost in the overflow...
We also fork the child process before setting up signals, so we wouldn't see the
SIGCHLD if the it died to soon (i.e. before the SIGUSR1/exec stuff, but that
would be an abnormal termination). The fix here is to prepare for SIGCHLD
before starting the child.
Another race I see is if the main process sent the SIGUSR1 before the child had
setup its handler -- this would cause the child to abort. We should get a
SIGCHLD in this case though, so while not desirable, it wouldn't cause your
hang. We should probably set SIGUSR1 blocked before forking anyway.
There's a tighter race between the child's calls to sigaction-ignore-SIGUSR1 and
then pause -- the signal could be lost in-between. I believe sigsuspend would
handle this more atomically.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10575
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.