[g++] programme avorté

Le
Stan
Bonjour,

Y-a-t-il des cas de plantage
qui ne générent pas de core dump ?

J'ai un programme qui plante de temps en temps
et je n'ai pas de trace de fichier core.

Merci.

[ freebsd 5.3, g++ (gcc) 3.4.2 ]
--
-Stan
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Ael Rowan Terence
Le #307173
"Stan" news:f33jt4$jbe$
Bonjour,

Y-a-t-il des cas de plantage
qui ne générent pas de core dump ?

J'ai un programme qui plante de temps en temps
et je n'ai pas de trace de fichier core.


Il se plante ? c'est à dire : il boucle indéfiniment ? il sort inopenament ?

Stan
Le #307172
"Ael Rowan Terence" news:f33si1$63v$

"Stan" news:f33jt4$jbe$
Bonjour,

Y-a-t-il des cas de plantage
qui ne générent pas de core dump ?

J'ai un programme qui plante de temps en temps
et je n'ai pas de trace de fichier core.


Il se plante ? c'est à dire : il boucle indéfiniment ? il sort inopenament
?




Il faut lire le titre ;-)
Il avorte, il sort prématurément; une boucle infinie, par elle même,
ne provoque pas de core dump.

--
-Stan


James Kanze
Le #307171
On May 24, 10:56 am, "Stan"
Y-a-t-il des cas de plantage
qui ne générent pas de core dump ?

J'ai un programme qui plante de temps en temps
et je n'ai pas de trace de fichier core.


Ça dépend de ce que tu endends par « planter ». Un programme
avec une erreur peut avoir beaucoup de comportements
différents : générer un core dump, tourner sans fin, donner de
mauvais résultats, etc. Il est aussi possible qu'il s'arrête
comme ça, sans donner de core. (Sous Unix, ça arrive la plupart
du temps à cause des problèmes avec un autre programme -- ce
qui provoke un SIGPIPE dans ton programme, par exemple. Ou un
SIGHUP, parce qu'on a oublié de le sortir du process group du
terminal.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze
Le #307170
On May 24, 1:16 pm, "Stan"
"Ael Rowan Terence"
"Stan" news:f33jt4$jbe$

Y-a-t-il des cas de plantage
qui ne générent pas de core dump ?

J'ai un programme qui plante de temps en temps
et je n'ai pas de trace de fichier core.


Il se plante ? c'est à dire : il boucle indéfiniment ? il
sort inopenament ?


Il faut lire le titre ;-)
Il avorte, il sort prématurément; une boucle infinie, par elle même,
ne provoque pas de core dump.


Avorter, en général, signifie qu'il termine suite à un SIGABRT.
Dans tel cas, il aurait normalement un core, au moins que la
configuration locale ne le permet pas. (Sous Unix, vérifier le
ulimit -c; si c'est 0, pas de core.)

En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Stan
Le #307169
"James Kanze"
En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.


Le programme est lancé depuis inetd ( xinetd pour être précis ),
de ce fait, je ne suis pas sûr de pouvoir retouver le signal.

--
-Stan

James Kanze
Le #307130
On May 24, 3:48 pm, "Stan"
"James Kanze"
En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.


Le programme est lancé depuis inetd ( xinetd pour être précis ),
de ce fait, je ne suis pas sûr de pouvoir retouver le signal.


En effet. Et tu ne peux pas réproduire l'erreur en le lançant
depuis un shell ?

Sinon, il faut écrire un tout petit programme qui le lance, qui
récupère l'état de sortie (signal, etc.), et qui l'écrit dans un
fichier de log, et configurer xinetd pour lancer ce petit
programme.

Aussi, si c'est un programme qui se lance à partir d'inetd (ou
d'un cron, ou d'un rc du système), il faut bien que tu lui
instrumentes, avec des logs, configuré par un fichier de
configuration. Ensuite, tu as les logs, pour voir ce qui était
la dernière chose que tu faisais.

--
James Kanze (Gabi Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


espie
Le #307129
In article James Kanze
On May 24, 3:48 pm, "Stan"
"James Kanze"
En gros, un processus sous Unix ne termine que parce qu'il a
appelé _exit() (suite à un retour de main, par exemple), soit
parce qu'il a reçu un signal. Dans le premier cas, le code de
retour sera normalement une valeur assez petite (mais rien
n'empêche qu'un programme renvoie des valeurs plus grandes) ;
dans le deuxième, le shell présente une valeur qui correspond au
numéro du signal plus 128. Tu dois donc pouvoir distinguer, et
même savoir de quel signal il s'agit.


Le programme est lancé depuis inetd ( xinetd pour être précis ),
de ce fait, je ne suis pas sûr de pouvoir retouver le signal.


En effet. Et tu ne peux pas réproduire l'erreur en le lançant
depuis un shell ?

Sinon, il faut écrire un tout petit programme qui le lance, qui
récupère l'état de sortie (signal, etc.), et qui l'écrit dans un
fichier de log, et configurer xinetd pour lancer ce petit
programme.


Normalement, un inetd bien foutu regarde le statut de retour des programmes
qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison
anormale (et normalement, ne relance PAS automatiquement le demon en
question, ce qui est logique).

Apres, les raisons de ne pas avoir de core-dump:
- le programme est lance dans un repertoire ou il ne peut pas ecrire: ca
peut etre tres possible s'il est lance avec sa propre uid dans un repertoire
appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le
repertoire en question en ecriture pour le groupe ou tout le monde).
- le programme est setuid. Les programmes setuid ne font normalement
pas de core. Normalement, ca se configure a coup de sysctl, ca.

Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...



Stan
Le #307128
"Marc Espie" news:f34u3u$1e6c$
Normalement, un inetd bien foutu regarde le statut de retour des
programmes

qu'il a lance... je sais que celui d'OpenBSD loggue toute terminaison
anormale (et normalement, ne relance PAS automatiquement le demon en
question, ce qui est logique).


Je ne sais pas ce qu'est un inetd "mal foutu", mais je ne pense pas
que le xinetd de la FreeBSD que j'utilise soit mal codé.
Or, mon application est bien relancé la fois suivante...

Apres, les raisons de ne pas avoir de core-dump:
- le programme est lance dans un repertoire ou il ne peut pas ecrire: ca
peut etre tres possible s'il est lance avec sa propre uid dans un
repertoire

appartenant a root (suffit dans ce cas-la de mettre TEMPORAIREMENT le
repertoire en question en ecriture pour le groupe ou tout le monde).


ce n'est pas le cas.

- le programme est setuid. Les programmes setuid ne font normalement
pas de core. Normalement, ca se configure a coup de sysctl, ca.



non plus.

Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...


Oui. Mais nous sommes des gens responsables, n'est-ce pas.
On peut admettre un léger bruit qui résulte forcément
de la réponse aux questions subsidiaires ;-)

--
-Stan

alex
Le #307025
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...


Oui. Mais nous sommes des gens responsables, n'est-ce pas.
On peut admettre un léger bruit qui résulte forcément
de la réponse aux questions subsidiaires ;-)


certes, mais admettez que quand qqn pose une question genre "comment faire
du réseau sous windows en C++" il est nettement plus vide redirigé vers la
sortie...

Les programmeurs C++, plutôt des unixiens que des windoweux ?


espie
Le #307022
In article alex
Mais bon, les rapports avec C++ sont extremement tenus... vaudrait
mieux aller faire un tour dans un groupe unix, a ce compte...


Oui. Mais nous sommes des gens responsables, n'est-ce pas.
On peut admettre un léger bruit qui résulte forcément
de la réponse aux questions subsidiaires ;-)


certes, mais admettez que quand qqn pose une question genre "comment faire
du réseau sous windows en C++" il est nettement plus vide redirigé vers la
sortie...


Pas tout a fait vrai. En ce qui me concerne, je considere que je l'ai
redirige vers la sortie, dans ce cas-aussi. La seule petite difference,
c'est que j'avais deux/trois pistes de reponse, ce qui est moins
souvent le cas sous windows.

Mais bon, il me semble que les windowsiens du coin sont generalement
exactement aussi civils: une indication de quoi faire, et zou direction
le groupe windows approprie.



Publicité
Poster une réponse
Anonyme