The completion of the child process can take place asynchronously or in one of the waitFor...() functions. In both cases, we used the same handler (_q_processDied()), which caused several problems: a. technically, waitForReadyRead() should have taken into account the result of the calls to _q_canRead...() slots inside the _q_processDied() function: - the user calls waitForReadyRead(); - forkfd descriptor becomes signaled, while a grandchild process is still alive; - as readyRead() signal has not been emitted, _q_processDied() is called; - the grandchild process writes to stdout pipe; - now data arrives, and _q_processDied() will collect it, but won't report it. b. we had a bug with recursions on Unix: - death notification comes asynchronously; - waitForDeadChild() closes forkfd; - _q_canRead...() emits readyRead(); - a slot connected to readyRead() calls waitForFinished(); - waitForFinished() hangs (forkfd == -1). c. for blocking functions, drainOutputPipes() was called twice on Windows. By introducing a new processFinished() function, we leave the read operations in the _q_processDied() slot, while the process completion code is guaranteed to run only once. Change-Id: I5f9d09bc68a058169de4d9e490b48fc0b35e94cd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>