Tracing through stap / stap-serverd signal handling, thence kill_stap_spawn(), thence spawned_pids_t::killall, one finds pthread mutex lock operations wrapping our reading of a set<pid_t>. That's not appropriate. We can't call pthread mutex ops from a signal handler at all; among other reasons, it's a deadlock recipe if the signal comes in at the wrong time. We can't just traverse the set<> locklessly either, because it may be in the middle of being updated by another thread. We need a signal-safe structure for collecting & iterating child pids.
(In reply to Frank Ch. Eigler from comment #0) > We need a signal-safe structure for collecting & iterating child pids. We may just need to make spawned_pids_t properly either-or, signal-safe or thread-safe but not both. At the moment, stap is single-threaded and calls kill_stap_spawn from a signal handler; stap-serverd is multithreaded but only kills via main. So stap only needs the signal-masking, and stap-serverd only needs the pthread mutex. (In fact, the use of sigprocmask is unspecified in multithreaded processes.) This is half-way selected by the SINGLE_THREADED macro now, but that's a big hammer, not even set by stap.