#266 closed defect (invalid)
waitForFinished() doesn't work
Reported by: | Silvan Scherrer | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Qt 5 |
Component: | General | Version: | 4.7.3 |
Severity: | low | Keywords: | |
Cc: | psmedley |
Description
I think there is a problem with waitForFinished() in 4.7
Scribus fails when trying to check if Ghostscript exists:
The code snippet is:
bool testGSAvailability( const QString& gsPath )
{
fprintf(stderr,"testGSAvailability( const QString& gsPath )\n");
QStringList args;
args.append( "-h" );
QProcess proc;
qDebug() << gsPath;
qDebug() << getShortPathName(gsPath);
proc.start(getShortPathName(gsPath), args);
if (!proc.waitForStarted(5000))
return false;
proc.waitForFinished(5000);
return (proc.exitCode()==0);
}
gsPath is e:/gs/gs8.71/bin/gsos2.exe and args = -h
proc.waitForFinished(5000) never returns. when I add a debug printf before and after it, only the first one prints...
Change History (11)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Cc: | added |
---|
comment:3 by , 13 years ago
Milestone: | Qt Enhanced → Qt 4.next |
---|
comment:4 by , 12 years ago
Milestone: | Qt 4.next → Qt 4.7.3 GA2 |
---|
comment:5 by , 12 years ago
Do you have to do anything special to make it hang? It works here. Regardless of whether the EXE is present or absent. In the former case your test function returns true, in the latter — false. (Which is correct).
Are you sure gsos2.exe doesn't hang in your case?
comment:6 by , 12 years ago
eventually also the main thread problem which we saw in smplayer and which is noted in the qprocess document is valid here.
comment:8 by , 12 years ago
Milestone: | Qt 4.7.3 GA2 → Qt 4.next |
---|
Yes, calling waitFor... functions on a GUI thread is kind of wrong.
However, I've just checked the current QProcess::waitFor impl and I see that I already added some sort of protection against this. I also created a fresh test case now where I call QProcess::waitForFinished() while running the GUI message loop (the dialog box is shown) and it still works here, no hangs.
So, if you still see hangs on your side, either the protection has some timing hole which lets a race slip in under certain conditions or there is a completely different reason for the hang. In either case, I can't do much w/o finding a way to reproduce it locally or debug it together with you.
I'm postponing this for the next milestone so far as nothing can be done ATM for GA2.
comment:9 by , 12 years ago
Sorry - I had forgotten I'd opened this. I recently solved the problem for the user.
They were using ghostscript linked against libc064 and scribus/qt linked against libc065
No problem if the libc064 forwarder is used.
In this case - the 'full' libc064 and libc065 were being used.
As soon as the user switched to for forwarder libc064 the problem went away.
comment:10 by , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
thx for letting us know, so we close it as invalid.
see also ticket:264 there was a similar issue