This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug runtime/10575] occasional stapio hangs for -c CMD


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]