Review Request: Workaround for the hang (freeze) when opening VLC's file dialog under KDE...

[Dawit A]

On Fri, Feb 4, 2011 at 5:00 PM, Thiago Macieira <thiago at kde.org> wrote:
> On Friday, 4 de February de 2011 16:35:32 Dawit A wrote:
>> Let us take out terminate from the equation. It is my mistake I
>> included it here because its documentation states that "The process
>> may not exit as a result of calling this function". However, I really
>> do not understand why what you stated matters for the kill() and timed
>> out scenarios...
>>
>> QProcess process;
>> process.start(...);
>>
>> If the next command I issue is
>>
>> process.waitForFinished();
>>
>> I expect it to wait 30 secs since that is what the default value for
>> the timeout parameter states. There is no way I would expect it to
>> block for another 30 sec when the variable goes out of scope because
>> of its own internal implementation issues. It is doing waitForFinished
>> on a child process it created itself. Nothing to do with the API
>> caller.
>
> Ok, that sounds like unexpected behaviour. Has this been filed as a bug?

Not yet. I simply mentioned it here because you seem to be addressing
the issue that exposed this behavior, but I guess I can open a ticket
against Qt for this.


>> The case of the kill is even more baffling to me because its
>> documentation clearly says "Kills the current process, causing it to
>> exit immediately". So If I kill is invoked as such
>>
>> process.kill();
>>
>> what should a reasonable expectation be ? To me the process gets
>> killed immediately. Done, poof, gone. Instead that too blocks for the
>> default amount of period if there are internally forked processes that
>> are still running when the dtor is encountered yet again.
>
> A killed process is still not reaped. Subprocesses need to be reaped by their
> parents to be cleaned up. There is more information that you can extract from
> a process after death, like CPU time consumed. So the implementation will have
> to clean up after the child process anyway.
>
> Is the problem that you're encountering that kill() doesn't kill the
> grandchildren processes?
>
> But I also don't see why a killed process would cause waitForFinished() to
> take more than some microseconds to complete. Do you have a testcase?

Yep, I do. It is the same thing I cobbled together to replicate the
VLC hang bug and posted a while back. I can dust that up and create
bug reports against Qt if you like.

Should I open two separate tickets for each one of these issue
eventhough the cause is the same, i.e. ~QProcess always calling
waitForFinished() so long as "d->processState != NoRunning" ?

1113	QProcess::~QProcess()
1114	{
1115	    Q_D(QProcess);
1116	    if (d->processState != NotRunning) {
1117	        qWarning("QProcess: Destroyed while process is still running.");
1118	        kill();
1119	        waitForFinished();
1120	    }
1121	#ifdef Q_OS_UNIX
1122	    // make sure the process manager removes this entry
1123	    d->findExitCode();
1124	#endif
1125	    d->cleanup();
1126	}

Please note that were it not for VLC blocking of the SIGCHLD signal, I
doubt I would have noticed this issue because the condition under
which waitForFinished is called in QProcess' dtor above would probably
never be met ??