waitForFinished() doesn't work

[Silvan Scherrer]

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...

[Silvan Scherrer]

see also ticket:264 there was a similar issue

[Dmitry A. Kuminov]

Do you have to do anything special to make it hang? It works here. Regardless of whether the EXE is present or absent. Are you sure gsos2.exe doesn't hang in your case?

[Silvan Scherrer]

eventually also the main thread problem which we saw in smplayer and which is noted in the qprocess document is valid here.

[Silvan Scherrer]

see ticket:264 for a complete description on the qprocess part

[Dmitry A. Kuminov]

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.

[psmedley]

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.

[Silvan Scherrer]

thx for letting us know, so we close it as invalid.

[Silvan Scherrer]

Milestone renamed