Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[g++] programme avorté

10 réponses
Avatar
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

10 réponses

Avatar
Ael Rowan Terence
"Stan" a écrit dans le message de
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 ?

Avatar
Stan
"Ael Rowan Terence" a écrit dans le message de
news:f33si1$63v$

"Stan" a écrit dans le message de
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


Avatar
James Kanze
On May 24, 10:56 am, "Stan" wrote:

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

Avatar
James Kanze
On May 24, 1:16 pm, "Stan" wrote:
"Ael Rowan Terence" a écrit dans le message denews:f33si 1$63v$
"Stan" a écrit dans le message de
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



Avatar
Stan
"James Kanze" a écrit dans le message de
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

Avatar
James Kanze
On May 24, 3:48 pm, "Stan" wrote:
"James Kanze" a écrit dans le message de

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


Avatar
espie
In article ,
James Kanze wrote:
On May 24, 3:48 pm, "Stan" wrote:
"James Kanze" a écrit dans le message de

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...



Avatar
Stan
"Marc Espie" a écrit dans le message de
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

Avatar
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...

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


Avatar
espie
In article <465f1aee$0$7501$,
alex wrote:
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.