probleme de code retour d execution
Le
ricky
bonjour,
je voulais faire un simple fork, avec le fils executant un code externe
sous redhat j avais ecrit un petit code du style :
int pif = fork();
if (pid == 0) { // le fils
int ret execvp("le programme externe", 0);
// ici je regarde le code retour
}
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour
est bon
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai
verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre
le code retour est -1 (et errno = 10) !!!
Je peut supprimer le fork(), et remplacer tout par :
int ret = system("mon programme externe");
J'ai le meme probleme :(
quelqu'un aurait une idée sur un code retour qui me semblerait erroné ???
merci
je voulais faire un simple fork, avec le fils executant un code externe
sous redhat j avais ecrit un petit code du style :
int pif = fork();
if (pid == 0) { // le fils
int ret execvp("le programme externe", 0);
// ici je regarde le code retour
}
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour
est bon
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai
verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre
le code retour est -1 (et errno = 10) !!!
Je peut supprimer le fork(), et remplacer tout par :
int ret = system("mon programme externe");
J'ai le meme probleme :(
quelqu'un aurait une idée sur un code retour qui me semblerait erroné ???
merci
Poser une question
Non. Ici, tu peux regarder le résultat de execvp quand il n'arrive
pas à lancer le programme externe, mais s'il y arrive, il ne retourne
jamais.
Non, jamais.
Non, avec system, tu as plein d'autres problèmes. Il vaut mieux
éviter system(3) en général.
Tu as une drôle de notion completement fantaisiste. Ça pourrait être
bien de lire quelque tutoriel ou livre sur la programmation unix...
En résumé, il faut distinger le résultat d'une fonction ou appel
système, du status retourné par un processus.
Les résultats sont retournés avec une instruction C return, et
récoltés comme résultat de l'expression appelant la fonction ou appel
système:
int execvp(...){
...
if(je_n_arrive_pas_a_executer_le_program){
errno=ESOMERROR;
return(1);
}
}
int res=execvp(...);
Tandis que le status d'un processus est composé de deux valeurs, un
code sur 8 bit indiquant si le status a été terminé normalement ou sur
réception d'un signal non traité, et d'une valeur sur 8 bit donnée par
le status via l'appel système _exit(2).
int pid=fork();
if(pid==0){
...
_exit(result);
}else{
int status=wait(pid);
if(WIFEXITED(status)){
int result=WEXITSTATUS(status);
...
}
...
}
--
__Pascal Bourguignon__ http://www.informatimago.com/
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
ais je ecrit le contraire ?
j'ai marque : "je regarde le code retour" ... s'il n'y a pas eu de
retour , c'est que cela s'est bien passe et cette ligne ne sert a rien
pour moi, sinon j'ai -1 ...
ais je ecrit que code retour bon impliquait une valeur ?
alors je vais preciser : il n'y a pas de -1 ... ca te va mieux ???
bon oki mais cette reponse n'a rien a voir avec le probleme, qui se
produit quelle que soit la methode d'appel, exec ou system...
avant cela fonctionnait, je voulais juste savoir en quoi un changement
d'os de redhat a centos pouvait modifier completement le comportement au
point de m'empecher d'avoir le bon resultat ..
euh, et toi de lire un message sans l'interpreter a ta guise ... ca
pourrait etre bien de ne pas condamner tout de suite ...
merci, j'en suis tout esbaudi :)
ouije le sais , je n'ai jamais ecrit le contraire !!!
et pour preciser mon probleme, les deux (status du processus ET code
retour) indiquent qu'il y a eu probleme, or tout s'est bien passé pour
le code appelé...
c'est ca mon problème ...
C'est impossible que ton programme lancé par execvp se déroule
correctement et que tu puisse par la suite consulter le code retour "ret".
Il manque alors un morceau de code dans ton exemple et tu consultes le
code retour dans le père et pas dans le fils ? car si le execvp est bien
déroulé, alors tout le code suivant l'instruction exec du fils n'est
jamais executé (c.f. man execvp).
Le errno correspond a une erreur "ECHILD No child process". Si tu
observe cette erreur ECHILD dans le fils après avoir fait le execvp,
c'est que ton programme externe n'est pas lancé.
Comment est lancé ton programme C ? par cron ? est-il lancé sous un
utilisateur particulier/different de celui avec lequel du developpe et
teste le programme ? variable d'environnement qui ont changé au passage
en centos4.0 (PATH, etc.), chemin d'accès a ton programme externe qui a
changé, repertoire qui ne sont plus accessbles à cet utilisateur ? ton
programme externe est un script dont l'interpreteur n'est pas installé/à
changé de place ?
je confirme, en fait, je me suis mal exprime !
j'ai un test sur le code retour, et si tout se passe bien, evidement ce
test n est jamais execute...
et dans le pere, j'ai un second test histoire de voir ce qui se passe
oui tout a fait !
j'ai un test du errno dans le pere, qui reste toujours a 10 que je lance
n'importe quoi en fait
Jusqu'a la centos, je n'ai jamais eu de probleme avec ce code...
oui tout a fait
Cela correspond aussi a une erreur SGNCHLD = SGN_IGN et aussi au cas ou
le fils teste n'appartient plus au pere. Mais ces deux cas ne semblent
pas correspondre non plus .
Si tu
non je confirme, errno est teste dans le pere, j'ai ete imprecis.
Mon programme a bien ecrit les fichiers qu'il est cense fournir, c'est
la mon probleme ! et j'ai mon errno malgre tout ..
Donc en fait, ce qui m ennuie, c'est que je ne peux pluis differencier
le cas ou mon programme a echoue de celui ou il a fonctionne
j'ai essaye un waitpid du fils, et le waitpid renvoie lui aussi les
memes codes
non a la main
est-il lancé sous un
j ai essaye de verifier tout ca, sans grand succes !
le plus "amusant" est que si je lance "gvd toto" a la place de "toto"
(gvd = l'interface du debugger), tout marche super bien, le debugger ne
remarque rien d'anormal et moi j'ai bien mon test du cote du pere qui
donne les bons resultats comme avant ... donc je ne peux pas le
debugger en utilisant ce moyen !