Не будет разницы никакой:

bool QProcess::waitForFinished(int msecs)
{
    Q_D(QProcess);
    if (d->processState == QProcess::NotRunning)
        return false;
    if (d->processState == QProcess::Starting) {
        QTime stopWatch;
        stopWatch.start();
        bool started = waitForStarted(msecs);
        if (!started)
            return false;
        if (msecs != -1)
            msecs -= stopWatch.elapsed();
    }

    return d->waitForFinished(msecs);
}

После вызова start() QProcess переходит в состояние Starting. Если даже это состояние поменялось на NotRunning в следтвии ошибки, то waitForFinished() об этом сразу увидит, если же мы всё еще в состоянии Starting, то он сам сам вызывает waitForStarted(). Ну и затем waitForFinished(), если всё удачно.



Проверь с какой-нибудь другой утилитой. Без QThread вообще код работал или всё написано с нуля без проверок?

Расскажи, что значит "вешается GUI"?

    int size_arguments = arguments.size() - 1;
    for(int i = 0; i <= size_arguments; i++)

наверное лучше изменить на:

    int size_arguments = arguments.size();
    for(int i = 0; i < size_arguments; i++)

Но с самого начала этот способ подвешивал GUI.

Вообще это всё странно, так как QProcess::start() работает в асинхронном режиме, в теории никакие QThread'ы не нужны, так как QProcess должен работать по аналогии с QNetworkAccessManager или QFtp.

А покажи код, который запускает этот поток + как он соединяется со слотами. Короче всю обвязку.

Проверь управление доходит до строчки идущей за waitForFinished(), если да, то скажи мне какая максимальная цифра в size_arguments.

Возможно это глупое предположение, но возможно программа слишком быстро запускается и завершается, настолько быстро, что долгий цикл:

    for(int i = 0; i < size_arguments; i++)
    {
        ...
    emit passChanged( i + 1 );
    }

Просто напросто "зафлуживает" GUI'шный поток сообщениями, на каждое из которых выполняется какая-нибудь не быстрая операция.

Так я и думал, новый поток запускается через start().