J'ai r=E9cement =E9t=E9 confront=E9 =E0 un probl=E8me que je n'ai su r=E9so=
udre : dans le main(), suite =E0 un exit(1), mon programme s'arretait en "s=
egmentation fault". Une fois le exit(1) remplac=E9 par un return 1, plus de=
probl=E8mes. (A titre d'informations, je n'ai eu ce probl=E8me que sous DE=
C OSF1. Sous HP-UX et sous GNU/Linux, aucun probl=E8mes)
J'aurais aim=E9 savoir si la norme pr=E9voyait un comportement diff=E9rent =
entre un appel =E0 exit(1) et =E0 return 1 dans le main. Je pensais que les=
deux fonctions appelaient les destructeurs des objets de main() puis les d=
estructeurs des objets globaux, mais le comportement ci-dessus semble montr=
er que non.
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un core dump ?
Avant tout, la présence d'un core dump signale à l'utilisateur que l'erreur est dans ton code, et non dans ses entrées.
Dans la pratique, avec un core dump, on peut, en général, obtenir un stack trace d'où le problème a eu lieu. Et donc, rétrouver l'erreur.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 15 Sep 2005 23:37:35 -0700, "kanze" <kanze@gabi-soft.fr>:
aussi la présence ou l'absence d'un core dump.
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un
core dump ?
Avant tout, la présence d'un core dump signale à l'utilisateur
que l'erreur est dans ton code, et non dans ses entrées.
Dans la pratique, avec un core dump, on peut, en général,
obtenir un stack trace d'où le problème a eu lieu. Et donc,
rétrouver l'erreur.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un core dump ?
Avant tout, la présence d'un core dump signale à l'utilisateur que l'erreur est dans ton code, et non dans ses entrées.
Dans la pratique, avec un core dump, on peut, en général, obtenir un stack trace d'où le problème a eu lieu. Et donc, rétrouver l'erreur.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Fabien LE LEZ wrote:
On Fri, 16 Sep 2005 20:16:45 +0200, Richard Delorme :
Avec le core-dump, qui est une image mémoire de l'application, le débogueur peut retrouver l'erreur sans avoir besoin de relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne toutes les infos utiles, c'est ça ?
On lui donne le nom de l'exécutable, et le nom du core dump.
L'intérêt, évidemment, c'est que le core dump s'est produit sur une machine où gdb n'est pas installé. On le récupère avec ftp, et on se sert de *son* copie de l'exécutable, ainsi que les sources locales.
- A remplir le disque dur, à la plus grande joie des vendeurs.
'sont pas effacées automatiquement, ces bestioles ?
Ça dépend. C'est effectivement assez habituel d'avoir un demon (job de cron) qui supprime tous les fichiers dont le nom est « core » et dont l'heure du dernier accès est plus d'une semaine en arrière. (Comment je le sais ? C'est évident, j'avais un fichier dont le nom était « core » que je voulais garder:-).)
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne s'appellent pas core, et qu'ils sont inhibés par défaut. (On a parfois l'impression que Linux cherche à émuler tous les côtés « jouet » de Windows.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Fri, 16 Sep 2005 20:16:45 +0200, Richard Delorme
<abulmo@nospam.fr>:
Avec le core-dump, qui est une image mémoire de l'application,
le débogueur peut retrouver l'erreur sans avoir besoin de
relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne
toutes les infos utiles, c'est ça ?
On lui donne le nom de l'exécutable, et le nom du core dump.
L'intérêt, évidemment, c'est que le core dump s'est produit sur
une machine où gdb n'est pas installé. On le récupère avec ftp,
et on se sert de *son* copie de l'exécutable, ainsi que les
sources locales.
- A remplir le disque dur, à la plus grande joie des vendeurs.
'sont pas effacées automatiquement, ces bestioles ?
Ça dépend. C'est effectivement assez habituel d'avoir un demon
(job de cron) qui supprime tous les fichiers dont le nom est
« core » et dont l'heure du dernier accès est plus d'une semaine
en arrière. (Comment je le sais ? C'est évident, j'avais un
fichier dont le nom était « core » que je voulais garder:-).)
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne
s'appellent pas core, et qu'ils sont inhibés par défaut. (On a
parfois l'impression que Linux cherche à émuler tous les côtés
« jouet » de Windows.)
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
On Fri, 16 Sep 2005 20:16:45 +0200, Richard Delorme :
Avec le core-dump, qui est une image mémoire de l'application, le débogueur peut retrouver l'erreur sans avoir besoin de relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne toutes les infos utiles, c'est ça ?
On lui donne le nom de l'exécutable, et le nom du core dump.
L'intérêt, évidemment, c'est que le core dump s'est produit sur une machine où gdb n'est pas installé. On le récupère avec ftp, et on se sert de *son* copie de l'exécutable, ainsi que les sources locales.
- A remplir le disque dur, à la plus grande joie des vendeurs.
'sont pas effacées automatiquement, ces bestioles ?
Ça dépend. C'est effectivement assez habituel d'avoir un demon (job de cron) qui supprime tous les fichiers dont le nom est « core » et dont l'heure du dernier accès est plus d'une semaine en arrière. (Comment je le sais ? C'est évident, j'avais un fichier dont le nom était « core » que je voulais garder:-).)
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne s'appellent pas core, et qu'ils sont inhibés par défaut. (On a parfois l'impression que Linux cherche à émuler tous les côtés « jouet » de Windows.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ
On Sun, 18 Sep 2005 12:41:34 +0200, James Kanze :
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne s'appellent pas core, et qu'ils sont inhibés par défaut. (On a parfois l'impression que Linux cherche à émuler tous les côtés « jouet » de Windows.)
C'est un peu ça. Linux se veut un système "grand public", ce qui est incompatible avec la notion d'un contact direct avec le programmeur en cas de plantage d'une application.
Pour la plupart des utilisateurs, un core dump ne peut servir à rien d'autre qu'à remplir le disque dur.
Et dans le cas d'une machine sur laquelle un core dump peut vraiment servir, il y a forcément un responsable technique (ne serait-ce que le programmeur lui-même) capable d'activer cette fonctionnalité.
On Sun, 18 Sep 2005 12:41:34 +0200, James Kanze <kanze@none>:
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne
s'appellent pas core, et qu'ils sont inhibés par défaut. (On a
parfois l'impression que Linux cherche à émuler tous les côtés
« jouet » de Windows.)
C'est un peu ça. Linux se veut un système "grand public", ce qui est
incompatible avec la notion d'un contact direct avec le programmeur en
cas de plantage d'une application.
Pour la plupart des utilisateurs, un core dump ne peut servir à rien
d'autre qu'à remplir le disque dur.
Et dans le cas d'une machine sur laquelle un core dump peut vraiment
servir, il y a forcément un responsable technique (ne serait-ce que le
programmeur lui-même) capable d'activer cette fonctionnalité.
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne s'appellent pas core, et qu'ils sont inhibés par défaut. (On a parfois l'impression que Linux cherche à émuler tous les côtés « jouet » de Windows.)
C'est un peu ça. Linux se veut un système "grand public", ce qui est incompatible avec la notion d'un contact direct avec le programmeur en cas de plantage d'une application.
Pour la plupart des utilisateurs, un core dump ne peut servir à rien d'autre qu'à remplir le disque dur.
Et dans le cas d'une machine sur laquelle un core dump peut vraiment servir, il y a forcément un responsable technique (ne serait-ce que le programmeur lui-même) capable d'activer cette fonctionnalité.
James Kanze
Fabien LE LEZ wrote:
On Sun, 18 Sep 2005 12:41:34 +0200, James Kanze :
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne s'appellent pas core, et qu'ils sont inhibés par défaut. (On a parfois l'impression que Linux cherche à émuler tous les côtés « jouet » de Windows.)
C'est un peu ça. Linux se veut un système "grand public", ce qui est incompatible avec la notion d'un contact direct avec le programmeur en cas de plantage d'une application.
Normalement, quand le programme arrive chez l'utilisateur, il ne doit plus y avoir de core dump. Au cas où il y en a, en revanche, l'utilisateur va bien vouloir se mettre en contact avec le programmeur (ou quelqu'un qui pourrait résoudre le problème).
Pour la plupart des utilisateurs, un core dump ne peut servir à rien d'autre qu'à remplir le disque dur.
Des deux choses une : ou bien, le programme ne se plante pas, il n'y a pas de core dump, et tout le monde est content, ou bien, il se plante, et l'utilisateur va vouloir une fixe, le plus vite possible. Il va donc contacter le service après-vente, qui va lui dire qu'il faut qu'il envoie le core.
Et dans le cas d'une machine sur laquelle un core dump peut vraiment servir, il y a forcément un responsable technique (ne serait-ce que le programmeur lui-même) capable d'activer cette fonctionnalité.
L'idée derrière le core dump, précisement, c'est que l'utilisateur ne peut pas faire la mise au point lui-même.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Sun, 18 Sep 2005 12:41:34 +0200, James Kanze <kanze@none>:
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne
s'appellent pas core, et qu'ils sont inhibés par défaut. (On a
parfois l'impression que Linux cherche à émuler tous les côtés
« jouet » de Windows.)
C'est un peu ça. Linux se veut un système "grand public", ce
qui est incompatible avec la notion d'un contact direct avec
le programmeur en cas de plantage d'une application.
Normalement, quand le programme arrive chez l'utilisateur, il ne
doit plus y avoir de core dump. Au cas où il y en a, en
revanche, l'utilisateur va bien vouloir se mettre en contact
avec le programmeur (ou quelqu'un qui pourrait résoudre le
problème).
Pour la plupart des utilisateurs, un core dump ne peut servir
à rien d'autre qu'à remplir le disque dur.
Des deux choses une : ou bien, le programme ne se plante pas, il
n'y a pas de core dump, et tout le monde est content, ou bien,
il se plante, et l'utilisateur va vouloir une fixe, le plus vite
possible. Il va donc contacter le service après-vente, qui va
lui dire qu'il faut qu'il envoie le core.
Et dans le cas d'une machine sur laquelle un core dump peut
vraiment servir, il y a forcément un responsable technique (ne
serait-ce que le programmeur lui-même) capable d'activer cette
fonctionnalité.
L'idée derrière le core dump, précisement, c'est que
l'utilisateur ne peut pas faire la mise au point lui-même.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Ça, c'est sous Unix. Sous Linux, j'ai remarqué que les core ne s'appellent pas core, et qu'ils sont inhibés par défaut. (On a parfois l'impression que Linux cherche à émuler tous les côtés « jouet » de Windows.)
C'est un peu ça. Linux se veut un système "grand public", ce qui est incompatible avec la notion d'un contact direct avec le programmeur en cas de plantage d'une application.
Normalement, quand le programme arrive chez l'utilisateur, il ne doit plus y avoir de core dump. Au cas où il y en a, en revanche, l'utilisateur va bien vouloir se mettre en contact avec le programmeur (ou quelqu'un qui pourrait résoudre le problème).
Pour la plupart des utilisateurs, un core dump ne peut servir à rien d'autre qu'à remplir le disque dur.
Des deux choses une : ou bien, le programme ne se plante pas, il n'y a pas de core dump, et tout le monde est content, ou bien, il se plante, et l'utilisateur va vouloir une fixe, le plus vite possible. Il va donc contacter le service après-vente, qui va lui dire qu'il faut qu'il envoie le core.
Et dans le cas d'une machine sur laquelle un core dump peut vraiment servir, il y a forcément un responsable technique (ne serait-ce que le programmeur lui-même) capable d'activer cette fonctionnalité.
L'idée derrière le core dump, précisement, c'est que l'utilisateur ne peut pas faire la mise au point lui-même.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ
On Sun, 18 Sep 2005 14:59:38 +0200, Fabien LE LEZ :
C'est un peu ça. Linux se veut un système "grand public", ce qui est incompatible avec la notion d'un contact direct avec le programmeur en cas de plantage d'une application.
Tiens, par exemple, réaction typique (de ma part) dans <news: : j'essaie VC++ 2005 beta, je m'aperçois qu'il ne compile pas mon code mieux que VC++ 2003, je laisse tomber et j'attends la version suivante. Sans Loïc, je n'aurais même pas eu l'idée de faire un rapport de bug. Et même après avoir rempli un rapport de bug, je suis quasi-sûr que ça ne servira à rien, et que mon code ne passera pas non plus dans la version finale.
Je peux me tromper, bien sûr (même Paco Rabanne se trompe parfois), mais je crois que ma réaction est typique -- l'idée étant qu'en cas de bug, l'utilisateur final ne peut rien faire.
Évidemment, si tu as acheté un logiciel dix mille francs, voire des centaines de milliers de francs, tu réagis différemment en cas de panne. Mais on est là très loin du domaine "grand public".
On Sun, 18 Sep 2005 14:59:38 +0200, Fabien LE LEZ
<gramster@gramster.com>:
C'est un peu ça. Linux se veut un système "grand public", ce qui est
incompatible avec la notion d'un contact direct avec le programmeur en
cas de plantage d'une application.
Tiens, par exemple, réaction typique (de ma part) dans
<news:pntni19l346c6883oojjg48ijkvki0aqal@4ax.com> : j'essaie VC++ 2005
beta, je m'aperçois qu'il ne compile pas mon code mieux que VC++ 2003,
je laisse tomber et j'attends la version suivante. Sans Loïc, je
n'aurais même pas eu l'idée de faire un rapport de bug. Et même après
avoir rempli un rapport de bug, je suis quasi-sûr que ça ne servira à
rien, et que mon code ne passera pas non plus dans la version finale.
Je peux me tromper, bien sûr (même Paco Rabanne se trompe parfois),
mais je crois que ma réaction est typique -- l'idée étant qu'en cas de
bug, l'utilisateur final ne peut rien faire.
Évidemment, si tu as acheté un logiciel dix mille francs, voire des
centaines de milliers de francs, tu réagis différemment en cas de
panne. Mais on est là très loin du domaine "grand public".
On Sun, 18 Sep 2005 14:59:38 +0200, Fabien LE LEZ :
C'est un peu ça. Linux se veut un système "grand public", ce qui est incompatible avec la notion d'un contact direct avec le programmeur en cas de plantage d'une application.
Tiens, par exemple, réaction typique (de ma part) dans <news: : j'essaie VC++ 2005 beta, je m'aperçois qu'il ne compile pas mon code mieux que VC++ 2003, je laisse tomber et j'attends la version suivante. Sans Loïc, je n'aurais même pas eu l'idée de faire un rapport de bug. Et même après avoir rempli un rapport de bug, je suis quasi-sûr que ça ne servira à rien, et que mon code ne passera pas non plus dans la version finale.
Je peux me tromper, bien sûr (même Paco Rabanne se trompe parfois), mais je crois que ma réaction est typique -- l'idée étant qu'en cas de bug, l'utilisateur final ne peut rien faire.
Évidemment, si tu as acheté un logiciel dix mille francs, voire des centaines de milliers de francs, tu réagis différemment en cas de panne. Mais on est là très loin du domaine "grand public".
Avec le core-dump, qui est une image mémoire de l'application, le débogueur peut retrouver l'erreur sans avoir besoin de relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne toutes les infos utiles, c'est ça ?
Note que Windows a aussi ses core dump (crash dump, minidump...), et que VC++ sait les analyser: http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
- A remplir le disque dur, à la plus grande joie des vendeurs.
Quand un programme se vautre, une boite de dialogue s'ouvre pour te demander si tu veux envoyer un rapport d'erreur à... Microsoft. Ainsi ce n'est pas ton disque dur que tu encombres, mais ceux des serveurs Microsoft. Et en plus tu rentabilises ton abonnement ADSL 8 Mo. Si c'est pas une preuve de supériorité de Windows :-)
-- Aurélien Regat-Barrel
Avec le
core-dump, qui est une image mémoire de l'application, le débogueur peut
retrouver l'erreur sans avoir besoin de relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne toutes les
infos utiles, c'est ça ?
Note que Windows a aussi ses core dump (crash dump, minidump...), et que
VC++ sait les analyser:
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
- A remplir le disque dur, à la plus grande joie des vendeurs.
Quand un programme se vautre, une boite de dialogue s'ouvre pour te
demander si tu veux envoyer un rapport d'erreur à... Microsoft. Ainsi ce
n'est pas ton disque dur que tu encombres, mais ceux des serveurs
Microsoft. Et en plus tu rentabilises ton abonnement ADSL 8 Mo.
Si c'est pas une preuve de supériorité de Windows :-)
Avec le core-dump, qui est une image mémoire de l'application, le débogueur peut retrouver l'erreur sans avoir besoin de relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne toutes les infos utiles, c'est ça ?
Note que Windows a aussi ses core dump (crash dump, minidump...), et que VC++ sait les analyser: http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
- A remplir le disque dur, à la plus grande joie des vendeurs.
Quand un programme se vautre, une boite de dialogue s'ouvre pour te demander si tu veux envoyer un rapport d'erreur à... Microsoft. Ainsi ce n'est pas ton disque dur que tu encombres, mais ceux des serveurs Microsoft. Et en plus tu rentabilises ton abonnement ADSL 8 Mo. Si c'est pas une preuve de supériorité de Windows :-)
