Problème avec QProcess

Version imprimable

Bonjour,

Debian/QTCreator last release.

Je rencontre quelques problèmes avec l'usage de QProcess. J'ai créé une fenêtre qui me permet d'indiquer le nom d'un programme à lancer et les arguments à passer.
A partir d'un bouton démarrer, je lance donc le programme grâce à un QProcess.

Dans un premier cas, je lance un programme test1 de ma fenêtre : pas de problème, ça fonctionne très bien.
Deuxième cas, je lance un programme test2 de ma fenêtre : le programme se lance mais bloque !!

J'ai essayé de varier les OpenMode sans succès. Je n'ai pas d'autres besoin dans ce lancement de connaître la fin du processus (pas d'échanges de données).

Et tout cela avec le même code (ci-dessous)

La différence notable entre test1 et test2 est que dans test2 j'accède à un fichier en lecture !!
J'ajoute que, lancés de la console de commande, test1 et test2 se comportent normalement.

Auriez-vous une piste de recherche, je sèche !!!

Merci d'avance, amicalement.

====
Code
====
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 // QProcess * pr est déclaré dans la classe serveur serveur::serveur(QWidget *parent) : QMainWindow(parent), ui(new Ui::serveur) { ui->setupUi(this); // initialisation de pr pr = new QProcess(this->parent()); // connexion signal - slot QObject::connect(pr, SIGNAL(finished(int, QProcess::ExitStatus)), this, SLOT(fin_calcul())); } void serveur::on_bouton_demarrer_clicked() { // setting de l'environnement QStringList env = QProcess::systemEnvironment(); pr->setEnvironment(env); // récupération à partir de QLineEdit du nom de la commande et des paramètres QString commande = ui->gene_prog->text(); QString params = ui->parametres->text(); if(!commande.isEmpty()) { // lancement du processus commande = "uc/" + commande; QStringList arguments = params.split(" "); pr->start(commande, arguments, QIODevice::NotOpen); } } void serveur::fin_calcul() { ui->bouton_demarrer->setText(QString::fromUtf8("Fin de la génération")); }

07/08/2009, 14h45
Gulish

On pourrait avoir plus de détails sur " le programme se lance mais bloque" ? Est ton interface qui se bloque, ou le programme lancé dans la console ?

En tout cas, il existe la méthode "startDetached()" dans QProcess, qui fait la même chose que start(), sauf que le process en question est éxécuté dans un nouveau thread (et pas celui de ta GUI). Ca résoudra peut être le problème.

G.
08/08/2009, 12h40
fabiop

Pour résumer :

De ma fenêtre Qt (en utilisant QProcess), je lance /sbin/mkdir avec comme argument toto, pas de problème, cela fonctionne aussi bien que lancé d'un terminal.
Je lance un autre programme test1 avec comme arguments 8 2, cela fonctionne aussi bien que lancé d'un terminal.
Je lance mon autre programme test2 avec comme arguments 8 2, le programme se lance mais se bloque avant d'exécuter une opération de sortie mais il ne se termine pas (je suis obligé de tuer le processus à la main). Sous le terminal, il fonctionne parfaitement. La seule différence avec test1 est que je fais une opération de lecture de fichier dans test2, au début du programme.

startDetached() ne change pas le problème et ne me permet plus de détecter la fin du processus.

En tout cas, merci pour ces pistes. Pour l'instant, je fais des essais sur l'environnement du processus selon qu'il est lancé du terminal ou de ma fenêtre Qt.

Amicalement.
08/08/2009, 16h37
Aurelien.Regat-Barrel

Citation:

Envoyé par Gulish

En tout cas, il existe la méthode "startDetached()" dans QProcess, qui fait la même chose que start(), sauf que le process en question est éxécuté dans un nouveau thread (et pas celui de ta GUI). Ca résoudra peut être le problème.

Oups, je crois que tu te mélanges les pinceaux ! QProcess lance un nouveau processus, aucun thread n'est jamais créé dans le processus père (à l'exception d'un thread de "monitoring" de tous les process lancés dans l'implémentation Win32). startDetached() se contente de lancer le nouveau processus et ne s'en occupe plus, contrairement à execute() qui attend la fin de son exécution pour renvoyer la valeur de retour. Ce sont toutes les deux des fonctions statiques.
Si on utilise une instance de QProcess, alors c'est start().

Citation:

Envoyé par fabiop

Pour résumer :

De ma fenêtre Qt (en utilisant QProcess), je lance /sbin/mkdir avec comme argument toto, pas de problème, cela fonctionne aussi bien que lancé d'un terminal.
Je lance un autre programme test1 avec comme arguments 8 2, cela fonctionne aussi bien que lancé d'un terminal.
Je lance mon autre programme test2 avec comme arguments 8 2, le programme se lance mais se bloque avant d'exécuter une opération de sortie mais il ne se termine pas (je suis obligé de tuer le processus à la main). Sous le terminal, il fonctionne parfaitement. La seule différence avec test1 est que je fais une opération de lecture de fichier dans test2, au début du programme.

startDetached() ne change pas le problème et ne me permet plus de détecter la fin du processus.

En tout cas, merci pour ces pistes. Pour l'instant, je fais des essais sur l'environnement du processus selon qu'il est lancé du terminal ou de ma fenêtre Qt.

Amicalement.

L'erreur numéro un est un mauvais répertoire courant. Avant d'appeler execute(), effectue un appel à QDir::setCurrent() pour régler comme tu le veux le répertoire courant du processus à lancer. Sinon, il ne va pas trouver le fichier que tu lui donnes vu qu'il ira regarder dans un autre répertoire...
08/08/2009, 17h42
fabiop

C'est ce qui s'est passé à peu près, je n'avais pas le retour d'erreur puisque pas de flux lisible à partir de mon programme lancé !

Merci beaucoup ... Ca m'a permis de bien bosser ce point ! smile
10/08/2009, 14h06
Gulish

Citation:

Oups, je crois que tu te mélanges les pinceaux ! QProcess lance un nouveau processus, aucun thread n'est jamais créé dans le processus père (à l'exception d'un thread de "monitoring" de tous les process lancés dans l'implémentation Win32). startDetached() se contente de lancer le nouveau processus et ne s'en occupe plus, contrairement à execute() qui attend la fin de son exécution pour renvoyer la valeur de retour. Ce sont toutes les deux des fonctions statiques.
Si on utilise une instance de QProcess, alors c'est start().

Es tu sûr ? Sous windows en tout cas, je suis quasiment sûr que l'application appelé est lancé dans un nouveau processus système. Il a même son propre PID, différent de celui de l'application qui l'a lancé. De plus dans la doc, il est écrit :

Citation:

Starts the program program with the given arguments in a new process

Pour moi, un process est un ensemble de threads. Je vais me renseigner pour être sûr.

G.

Edit : (Je ne parle que de windows, sous unix je ne sais pas)Pour la différence entre start() et startDetached(), tu avais en partie raison, la différence est que l'un attend le retour de l'éxécution, l'autre non. Par contre, selon moi (à confirmer), les 2 fonctions créent un nouveau processus système et donc un nouvel ensemble de threads. J'ai parcouru le code de qprocess et le start appel cette fonction : (et la msdn dit)

Citation:

CreateProcess Function
Creates a new process and its primary thread. The new process runs in the security context of the calling process.

A confirmer,

G.
11/08/2009, 03h07
Aurelien.Regat-Barrel

Citation:

Envoyé par Gulish

Es tu sûr ? Sous windows en tout cas, je suis quasiment sûr que l'application appelé est lancé dans un nouveau processus système.

Ben c'est ce que je pensais avoir dit :D

Citation:

Envoyé par Gulish

Par contre, selon moi (à confirmer), les 2 fonctions créent un nouveau processus système et donc un nouvel ensemble de threads.

Oui bien sûr chaque process dispose de son thread principal, mais quand on dit "créer un thread", on parle de créer un thread supplémentaire au sein du processus appelant. Car si on veut être précis, c'est pas QProcess / CreateProcess qui crée explicitement le thread dans le nouveau process, mais l'OS. Pour créer un thread, on utilise... QThread.

Toutes les fonction (start(), startDetached(), execute()) créent un nouveau processus. La différence concerne simplement comment QProcess interagit avec ce processus.