Details
-
Bug
-
Resolution: Out of scope
-
Not Evaluated
-
None
-
5.11.1
-
None
Description
Downstream bug: https://bugs.kde.org/show_bug.cgi?id=394360
The symptom is that QProcess:waitForFinished never returns although the child exited and it stays around as a zombie.
It's not always reproducible, but the cause was found with strace to be the removal of the sigchld handler (quoting the comment on the downstream bug):
16233 exit_group(0) = ?
16233 +++ exited with 0 +++
13987 <... ppoll resumed> ) = ? ERESTARTNOHAND (To be restarted if no handler)
13987 — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16233, si_uid=500, si_status=0, si_utime=0, si_stime=0} ---
13987 ppoll([\{fd=-1}, \{fd=-1}, \{fd=-1}, \{fd=46, events=POLLIN}], 4, NULL, NULL, 8 <unfinished ...>
13990 <... poll resumed> ) = 1 ([\{fd=3, revents=POLLIN}])If I interpret this correctly, kdeinit was currently doing a ppoll (no sigmask, so == poll) and it had no handler, as otherwise it would've donene of the calls in the handler and not continue with ppoll.
This seems to explain it:
13987 rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f0242406110}, NULL, 8) = 0
It's the last call to rt_sigaction in that process, so it removed its signal handler, so it's no surprise it stays a zombie...
Now the question is where the rt_sigaction call comes from. It might be somewhere in forkfd.
With QT_NO_GLIB=1 it seems to work.
Attachments
Issue Links
- duplicates
-
QTBUG-56338 QProcess::waitForFinished waits forever on a zombie process
- Closed