programme ABORTED : pourquoi ?

Cela veut dire qu'une API d'une bibliotheque a rencontré un probleme, elles
s'est tuée
elle même,c'est souvent dans le cadre de la programmation d'erreur, lors
d'une anomalie detectée
par l'api. exemple, un handler null ou un fichier manquant, un probleme de
version sur
un objet, l'echec d'un appel systeme.

ca peut etre aussi un include qui manque sur le typage des variables, genre
math.h, si elle manque
les variables sont typées int au lieu de float,long,double.

genre
/* erreur grave detectee, hander vide */
if ( monhanlder == NULL)
kill(SIGABORT)

essayez de compiler vos programmes avec cc -g machin.c -o toto

l'option -g genere les informations qui permmettent de mieux suivre au
debuger

dans gdb

gdb toto
run toto
attendre le planton

tapez where

vous pourrez voir avec "where" l'etat de la pile et sur quel appel de
function ca plante.

sinon dans pire suivre en pas a pas ,

gdb toto
stop in main
run
ou
run -x argument1 -p argument2

attendre le point d arret
next execute la prochaine ligne
next

si besoin, tapez stop in "le_nom_de_ma_function"
si besoint tapez stop at "mon_no_ligne"
si besoin tapez step entre dans l'appel de la fonction

list 100-150 ou 100,150

Malheureusement, e contexte que vous decrivez est encore assez vague pour
etre plus precis.

<user@domain.invalid> a écrit dans le message de
news:4100c54a$0$29428$626a14ce@news.free.fr...

Bonjour,

Je travaille sur un programme C++ en ligne de commande.
Pour une raison encore indéterminée, mon programme s'arrête soudainement
avec l'indication "ABORTED"

gdb que j'utilise pour la première fois précise :
<<
Program received signal SIGABRT, Aborted.
0x400c1621 in kill () from /lib/libc.so.6
(gdb) where
#0 0x400c1621 in kill () from /lib/libc.so.6
#1 0x400c1425 in raise () from /lib/libc.so.6
#2 0x400c2a53 in abort () from /lib/libc.so.6

Quelle betise fait donc mon programme
pour être ainsi puni d'un SIGABRT ?
Fuite de mémoire, peut-être ?

Quelqu'un aurait-il une suggestion pour rechercher l'erreur ?
indications :
celeron 800 MHz 128 Mo de memoire vive
Mandrake 8.2 kernel 2.4.18-6mdk
g++ 2.96
gdb 5.1.1

Par avance merci.
Cordialement,
MG

Bonjour,

Jean-Pierre B. a écrit:

Cela veut dire qu'une API d'une bibliotheque a rencontré un probleme, elles
s'est tuée
elle même,c'est souvent dans le cadre de la programmation d'erreur, lors
d'une anomalie detectée
par l'api. exemple, un handler null ou un fichier manquant, un probleme de
version sur
un objet, l'echec d'un appel systeme.
==> code à relire en détails.

ca peut etre aussi un include qui manque sur le typage des variables, genre
math.h, si elle manque
les variables sont typées int au lieu de float,long,double.
Je vérifierai. ça coute rien de l'indiquer dans tous les en-têtes pour

être sur de ne pas l'oublier.

genre
/* erreur grave detectee, hander vide */
if ( monhanlder == NULL)
kill(SIGABORT)

essayez de compiler vos programmes avec cc -g machin.c -o toto

l'option -g genere les informations qui permmettent de mieux suivre au
debuger

dans gdb

gdb toto
run toto
attendre le planton

tapez where

vous pourrez voir avec "where" l'etat de la pile et sur quel appel de
function ca plante.

J'ai fait tout ça mais "where" ne me donne pas la quelle de *mes* lignes
de code posent problème.
il me dit :

(gdb) where
#0 0x400c1621 in kill () from /lib/libc.so.6
#1 0x400c1425 in raise () from /lib/libc.so.6
#2 0x400c2a53 in abort () from /lib/libc.so.6

Je vais regarder plus en détail la commande 'where' pour aller au delà
de #2. ça doit être possible.
Bref, il faut que :
- je "blinde" mon code en testant toutes mes variables ;
- je regarde les fonctions de gdb pour avoir plus d'infos.

sinon dans pire suivre en pas a pas ,
:-/ mouais. Il tourne très bien un bon moment (j'ai deux boucles for

imbriquées) et ça risque d'être long en "pas à pas". Mais à défaut de
mieux...

Merci de vos indications.
Je regarderai ça ce soir.

Cordialement,
MG

gdb toto
stop in main
run
ou
run -x argument1 -p argument2

attendre le point d arret
next execute la prochaine ligne
next

si besoin, tapez stop in "le_nom_de_ma_function"
si besoint tapez stop at "mon_no_ligne"
si besoin tapez step entre dans l'appel de la fonction

list 100-150 ou 100,150

Malheureusement, e contexte que vous decrivez est encore assez vague pour
etre plus precis.

<user@domain.invalid> a écrit dans le message de
news:4100c54a$0$29428$626a14ce@news.free.fr...

Bonjour,

Je travaille sur un programme C++ en ligne de commande.
Pour une raison encore indéterminée, mon programme s'arrête soudainement
avec l'indication "ABORTED"

gdb que j'utilise pour la première fois précise :
<<
Program received signal SIGABRT, Aborted.
0x400c1621 in kill () from /lib/libc.so.6
(gdb) where
#0 0x400c1621 in kill () from /lib/libc.so.6
#1 0x400c1425 in raise () from /lib/libc.so.6
#2 0x400c2a53 in abort () from /lib/libc.so.6

Quelle betise fait donc mon programme
pour être ainsi puni d'un SIGABRT ?
Fuite de mémoire, peut-être ?

Quelqu'un aurait-il une suggestion pour rechercher l'erreur ?
indications :
celeron 800 MHz 128 Mo de memoire vive
Mandrake 8.2 kernel 2.4.18-6mdk
g++ 2.96
gdb 5.1.1

Par avance merci.
Cordialement,
MG

user@domain.invalid <user@domain.invalid> écrit:

gdb que j'utilise pour la première fois précise :
<<
Program received signal SIGABRT, Aborted.
0x400c1621 in kill () from /lib/libc.so.6
(gdb) where
#0 0x400c1621 in kill () from /lib/libc.so.6
#1 0x400c1425 in raise () from /lib/libc.so.6
#2 0x400c2a53 in abort () from /lib/libc.so.6

Quelle betise fait donc mon programme
pour être ainsi puni d'un SIGABRT ?
Fuite de mémoire, peut-être ?

Non. en C, ça correspond souvent à un assert() non vérifié.

Quelqu'un aurait-il une suggestion pour rechercher l'erreur ?

Dans la ligne après le abort() de gdb.

vous pourrez voir avec "where" l'etat de la pile et sur quel appel de
function ca plante.

J'ai fait tout ça mais "where" ne me donne pas la quelle de *mes* lignes
de code posent problème.

vous avez recompile tous vos modules applicatifs (module).c avec
l'option -g ?

ca faît peu comme info sur la pile, on ne voit que la fonction abort()
qui appelle raise() qui appelle kill()

la fonction abort() est celle qui declenche le SIGABORT
elle est forcément appelée quelque part, ou alors vous avez linké des lib
systeme qui ne sont pas compatible entre elle dans votre executable, pas
d'erreur
a la compile mais planton lors de l'execution.

ce qui expliquerait son declenchement pour incompatibiliter.

faire grep de la fonction "abort()" dans vos modules .c
au cas que ca soit géré applicativement

Vous pouvez ajouter des trace dans chaque appel de fonction (debut/fin)
en sortie ecran ou fichier.log

cdt

il me dit :

(gdb) where
#0 0x400c1621 in kill () from /lib/libc.so.6
#1 0x400c1425 in raise () from /lib/libc.so.6
#2 0x400c2a53 in abort () from /lib/libc.so.6

Je vais regarder plus en détail la commande 'where' pour aller au delà
de #2. ça doit être possible.
Bref, il faut que :
- je "blinde" mon code en testant toutes mes variables ;
- je regarde les fonctions de gdb pour avoir plus d'infos.

sinon dans pire suivre en pas a pas ,
:-/ mouais. Il tourne très bien un bon moment (j'ai deux boucles for

imbriquées) et ça risque d'être long en "pas à pas". Mais à défaut de
mieux...

Merci de vos indications.
Je regarderai ça ce soir.

Cordialement,
MG

gdb toto
stop in main
run
ou
run -x argument1 -p argument2

attendre le point d arret
next execute la prochaine ligne
next

si besoin, tapez stop in "le_nom_de_ma_function"
si besoint tapez stop at "mon_no_ligne"
si besoin tapez step entre dans l'appel de la fonction

list 100-150 ou 100,150

Malheureusement, e contexte que vous decrivez est encore assez vague
pour

etre plus precis.

<user@domain.invalid> a écrit dans le message de
news:4100c54a$0$29428$626a14ce@news.free.fr...

Bonjour,

Je travaille sur un programme C++ en ligne de commande.
Pour une raison encore indéterminée, mon programme s'arrête soudainement
avec l'indication "ABORTED"

gdb que j'utilise pour la première fois précise :
<<
Program received signal SIGABRT, Aborted.
0x400c1621 in kill () from /lib/libc.so.6
(gdb) where
#0 0x400c1621 in kill () from /lib/libc.so.6
#1 0x400c1425 in raise () from /lib/libc.so.6
#2 0x400c2a53 in abort () from /lib/libc.so.6

Quelle betise fait donc mon programme
pour être ainsi puni d'un SIGABRT ?
Fuite de mémoire, peut-être ?

Quelqu'un aurait-il une suggestion pour rechercher l'erreur ?
indications :
celeron 800 MHz 128 Mo de memoire vive
Mandrake 8.2 kernel 2.4.18-6mdk
g++ 2.96
gdb 5.1.1

Par avance merci.
Cordialement,
MG

Bonjour,

Jean-Pierre B. a écrit:

vous pourrez voir avec "where" l'etat de la pile et sur quel appel de
function ca plante.

J'ai fait tout ça mais "where" ne me donne pas la quelle de *mes* lignes
de code posent problème.

vous avez recompile tous vos modules applicatifs (module).c avec
l'option -g ?
Oui. Mais je controlerai.

ca faît peu comme info sur la pile, on ne voit que la fonction abort()
qui appelle raise() qui appelle kill()
J'ai cherché sur le net. Je vais essayer avec "bt" (bt 10) par exemple

pour avoir une liste plus longue.

la fonction abort() est celle qui declenche le SIGABORT
elle est forcément appelée quelque part, ou alors vous avez linké des lib
systeme qui ne sont pas compatible entre elle dans votre executable, pas
d'erreur
a la compile mais planton lors de l'execution.
Un mélange de gcc 2.96 et gcc3.xx par exemple ?

Sinon, je n'ai pas modifié les librairies fournies avec la distribution.

ce qui expliquerait son declenchement pour incompatibiliter.

faire grep de la fonction "abort()" dans vos modules .c
au cas que ca soit géré applicativement
Je n'ai jamais utilisé la fonction abort() moi-même.

ça ne peut venir, de toute façon des librairies système.

Vous pouvez ajouter des trace dans chaque appel de fonction (debut/fin)
en sortie ecran ou fichier.log
J'avais utilisé ça avant d'essayer gdb.

ya plus qu'a affiner la recherche du problème et vérifier en même temps
mes variables.

Merci.
MG

Bonjour

user@domain.invalid wrote:

g++ 2.96

Y a pas moyen de changer ce compilo ?
avec tout ce qu'on en dit, vaut miuex car si vpus cherchez bien, dans
les threads recents de fcolc , et fclc, 2.96 c'est un cru bien special.


--
Rakotomandimby Mihamina Andrianifaharana
Tel : +33 2 38 76 43 65
http://www.rktmb.org/Members/mihamina

Bonjour,

Rakotomandimby Mihamina a écrit:

Mon humble avis de debutant est qu'il faudrait dans un premier temps
revoir la versionde compilo que l'on utilie.

Il y a de (tres) fortes chances pour que du code compilé avec gcc (et/ou
g++) 2.96 aie besoin d'etre reecrit pour compiler sous un futur compilo.

gcc 2.96 est une version qui est sortie par accident, vous vous casserez
les dents a essayer de faire marcher votre code avec 2.96, mais vous
aurez a reecrire votre code pour le compiler avec 3.x ...

Je crois que j'ai également une version 3. de gcc sur ma distribution
linux (que je n'ai pas sous la main : chez moi sur mon portable).
Je vais essayer de voir comment forcer l'utilisation de gcc 3.
Ou alors voir à utiliser un CD linux live plus récent que ma distrib.

Je l'ai dit une fois, je le redis (on ne sait jamais), maintenant, a bon
entendeur, salut.
Bien entendu.

Merci de votre aide.
cordialement,
MG

Mon humble avis de debutant est qu'il faudrait dans un premier temps
revoir la versionde compilo que l'on utilie.

Il y a de (tres) fortes chances pour que du code compilé avec gcc (et/ou
g++) 2.96 aie besoin d'etre reecrit pour compiler sous un futur compilo.

gcc 2.96 est une version qui est sortie par accident, vous vous casserez
les dents a essayer de faire marcher votre code avec 2.96, mais vous
aurez a reecrire votre code pour le compiler avec 3.x ...

Je l'ai dit une fois, je le redis (on ne sait jamais), maintenant, a bon
entendeur, salut.
--
Rakotomandimby Mihamina Andrianifaharana
Tel : +33 2 38 76 43 65
http://www.rktmb.org/Members/mihamina

Rakotomandimby Mihamina a écrit:

Mon humble avis de debutant est qu'il faudrait dans un premier temps
revoir la versionde compilo que l'on utilie.

Le lien que voici confirme votre défiance à l'égard de mon compilateur.
http://www.mplayerhq.hu/DOCS/HTML/fr/gcc-296.html
Je vais donc installer la version gcc 3.0 de mandrake 8.2.

Merci à vous,
MG

user@domain.invalid wrote:

Je vais essayer de voir comment forcer l'utilisation de gcc 3.

il n'y a pas a forcer quoi que ce soit en fait:

http://gcc.gnu.org/ml/gcc/2002-05/msg02554.html
http://fcolc.rktmb.org/Members/mihamina/liens/gcc3mdk82/link_view
http://fcolc.rktmb.org/Members/mihamina/liens/gcc30mdk82/link_view
--
Rakotomandimby Mihamina Andrianifaharana
Tel : +33 2 38 76 43 65
http://www.rktmb.org/Members/mihamina