Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#266 closed defect (invalid)

waitForFinished() doesn't work

Reported by: diver 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 Changed 7 years ago by diver

see also ticket:264 there was a similar issue

comment:2 Changed 7 years ago by psmedley

  • Cc psmedley added

comment:3 Changed 7 years ago by diver

  • Milestone changed from Qt Enhanced to Qt 4.next

comment:4 Changed 6 years ago by dmik

  • Milestone changed from Qt 4.next to Qt 4.7.3 GA2

comment:5 Changed 6 years ago by dmik

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?

Last edited 6 years ago by dmik (previous) (diff)

comment:6 Changed 6 years ago by diver

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

comment:7 Changed 6 years ago by diver

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

comment:8 Changed 6 years ago by dmik

  • Milestone changed from Qt 4.7.3 GA2 to 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 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by diver

  • Resolution set to invalid
  • Status changed from new to closed

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

comment:11 Changed 4 years ago by diver

  • Milestone changed from Qt 4.next to Qt 5

Milestone renamed

Note: See TracTickets for help on using tickets.