Accès Premium
GNT sans publicité, site mobile, fonctionnalitées exclusives...
Rejoignez-nous !
Forums Linux Unix

programme ABORTED : pourquoi ?

Le
user
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
Lire les 11 réponses

Questions / Réponses high-tech
Poser une question
Vidéos High-Tech et Jeu Vidéo
Plus de vidéos
Téléchargements
Plus de téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Pierre B.
Le #480841
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.

news:4100c54a$0$29428$
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





Répondre en citant
user
Le #480840
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.

news:4100c54a$0$29428$

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










Répondre en citant
Laurent Wacrenier
Le #480586
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.



Répondre en citant
Jean-Pierre B.
Le #480585
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.

news:4100c54a$0$29428$

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













Répondre en citant
user
Le #480583
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



Répondre en citant
Publicité
Suivre les réponses
Poster une réponse
Anonyme