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.
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.
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.
"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
?
"Stan" <none@none.invalid> a écrit dans le message de
news:f33jt4$jbe$1@s1.news.oleane.net...
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" 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
?
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.
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.
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.
"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.
"Ael Rowan Terence" <N...@Null.fr> a écrit dans le message denews:f33si 1$63v$1@news1.completel.net...
"Stan" <n...@none.invalid> a écrit dans le message de
news:f33jt4$jbe$1@s1.news.oleane.net...
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.
"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.
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.
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.
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" a écrit dans le message deEn 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.
"James Kanze" <james.ka...@gmail.com> 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.
"James Kanze" a écrit dans le message deEn 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.
On May 24, 3:48 pm, "Stan" wrote:"James Kanze" a écrit dans le message deEn 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.
On May 24, 3:48 pm, "Stan" <n...@none.invalid> wrote:
"James Kanze" <james.ka...@gmail.com> 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.
On May 24, 3:48 pm, "Stan" wrote:"James Kanze" a écrit dans le message deEn 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...
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...
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...
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 ;-)
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 ;-)
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 ;-)
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...
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...
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...