Pb coredump dans boucle en 64 bits

Bonjour,

J'utilise un AIX 5.3 et compile mes programmes C avec Visual Age 6.0

Dans un programme C le code suivant fonctionne très bien lorsque mon programme est compilé en 32 bits :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

... /* The path must be removed from the file name */ for (i_id=0, i_lg=strlen(s_namfile); s_namfile[i_lg] != '/'; i_lg--) { i_id = i_id + 1; } for (i_id=0, i_lg=i_lg+1; s_namfile[i_lg] != '\0'; i_lg++) { s_parfile[i_id] = s_namfile[i_lg]; i_id = i_id + 1; } s_parfile[i_id] = '\0'; ...

---

Mais une fois compilé en 64 bits j'ai un coredump qui apparait lors de son exécution.
Un dépassement de mémoire j'imagine...
La partie du code qui pose pb est celle en gras.

Comment ne plus avoir ce dépassement de mémoire en 64 bits ? Il faut jouer avec les \0 je pense, mais je n'y connait rien en C.

Pouvez-vous m'aider svp ?

Merci

Il faudrait d'abord que tu lances le programme en mode debug avec un debugger ou alors que tu analyses la stack du core généré (toujours avec le debugger) afin de voir où cela se crash vraiment et à cause de quoi (indice hors bande, mauvais pointeur, string mal terminées, ...).

Ensuite, on verra ...

On part du principe que ta chaîne est bien une réelle chaîne (c'est-à-dire terminée par un '\0'). Il faut bien vérifier dans ton code si c'est le cas, sinon c'est crash assuré.

Ensuite, es-tu certaine que ta chaîne s_namfile comporte bien un slash à l'intérieur ? Car si ce n'est pas le cas, on court à la catastrophe. :aie: Il faut gérer cette possibilité.
En outre, je ne comprends pas l'utilité d'incrémenter i_id dans ta première boucle puisque au lancement de la seconde, tu mets cette variable à 0.

J'ai modifié un peu ton code, cela fonctionne chez moi :

Code:

---

1 2 3 4 5 6 7 8

for (i_lg=strlen(s_namfile) ; i_lg>=0 && s_namfile[i_lg] != '/'; i_lg--) ;   i_id=0; if (s_namfile[i_lg] == '/') /* sommes-nous bien sortis de la boucle par la présence du slash ? */ for (i_lg++ ; s_namfile[i_lg] != '\0'; i_lg++, i_id++) s_parfile[i_id] = s_namfile[i_lg];   s_parfile[i_id] = '\0';

---

Si la chaîne ne contient pas de slash ou que ce slash est le dernier caractère, alors s_partfile sera une chaîne vide (constituée d'un '\0' seulement). Dans le cas contraire, s_partfile contiendra tout ce qui est situé après le dernier slash (au cas où la chaîne s_namfile en contiendrait plusieurs) jusqu'au '\0' final (inclus, donc).

Je précise (c'est important !) que i_lg>=0 ne sera correct que si i_lg est un type signé. Il faudra sinon manoeuvrer autrement.
Je ne sais pas quel type tu utilises pour cette variable dans ton programme, j'ai fait au plus simple dans un premier temps.

Merci pour vos réponse...

Jeroman,

La chaine s_namfile vaut : /home/rep/toto_20090724_104950_676032

je ne sais pas si elle se termine par un '\0'

Je sais que le programme marche en 32 bits donc j'imagine que oui, mais admettons que ça ne soit pas le cas, est-ce que je peux faire ça au début :

Code:

---

1 2 3

i_id=strlen(s_namfile)+1; s_namfile[i_id] = '\0';

---

Donc ici, si je comprends bien, là je rajoute '\0' à la fin de ma variable s_namfile


sinon la déclaration de i_lg est faite comme ça :

Code:

---

1 2	int i_lg, i_id;

---

Je vais essayer ton code avec :

Code:

---

1 2 3

int signed i_lg; int i_id;

---

Bon, j'ai toujours mon erreur...

Par contre j'ai compilé avec l'option -g et exécuté mon programme avec dbx et voici l'erreur que j'obtiens :

Citation:

---

Segmentation fault in strlen.strlen [/lib/libc.a] at 0x90000000003b024 ($t1)
0x90000000003b024 (strlen+0x24) 88ac0000 lbz r5,0x0(r12)

---

Je ne comprends pas ce que ça veut dire. Quelqu'un peut m'aider pour décrire ce résultat svp ?

soit tu mesures la longueur d'une chaine de caractères qui n'est pas finie par un 0
soit tu mesures la longueur d'une chaine de caractère et le pointeur de cette chaine de caractères est "fou" (valeur aléatoire qui pointe n'importe où)

le but de ton algo est de récupérer le nom du fichier?

tu peux eventuellement regarder si cette fonction existe sur AIX
http://docs.sun.com/app/docs/doc/816...name-3c?a=view

Citation:

---

Envoyé par Cathy

Bon, j'ai toujours mon erreur...

Par contre j'ai compilé avec l'option -g et exécuté mon programme avec dbx et voici l'erreur que j'obtiens :



Je ne comprends pas ce que ça veut dire. Quelqu'un peut m'aider pour décrire ce résultat svp ?

---

relance ton programme en ayant tappé 'ulimit -c unlimited' avant

quand tu vas relancer tu aura un fichier coredump qui sera généré.

ensuite lance le debugger avec ton programme et le fichier coredump en paramètre

si c'est gdb tu peux faire comme ça

gdb mon_programe fichier_core

un fois dans gdb tappe "where" ou "bt" normalement cela te donnera la ligne ou ton programme a crashé


petit lien utile
http://www.ibm.com/developerworks/library/l-gdb/

Citation:

---

Segmentation fault in strlen.strlen [/lib/libc.a] at 0x90000000003b024 ($t1)
0x90000000003b024 (strlen+0x24) 88ac0000 lbz r5,0x0(r12)

---

Normalement avec ces information et ton exécutable tu peux retrouver la ligne ou ça a planté grace a un petit calcul sur les adresse et la table des symboles de ton exe, mais je ne sais plus le faire :'(

Citation:

---

La chaine s_namfile vaut : /home/rep/toto_20090724_104950_676032

---

Comment cette chaîne est-elle créée ? Montre le code correspondant. Il faut absolument être sûr que cette chaîne se termine bien par un '\0'. Sinon, c'est le crash assuré.

Citation:

---

i_id=strlen(s_namfile)+1;
s_namfile[i_id] = '\0';

---

Risque de crash : tu accèdes à un emplacement mémoire situé au-delà de la chaîne.
Même en virant le +1, cela n'aurait aucun intérêt car strlen calcule la longueur de la chaîne, c'est-à-dire le nombre de caractères jusqu'à ce qu'il rencontre un '\0' (ce caractère ne fait pas partie du comptage).
Par exemple, si tu as la chaîne bidule qui contient "ABCD\0", strlen(bidule) te renverra 4. Or si tu fais bidule[4] cela correspond à l'emplacement du '\0'. Ecrire '\0' sur un '\0' n'a donc aucun intérêt.

JEROMAN :

Alors voici comment est contruite la chaine s_namfile :

Code:

---

1 2 3 4 5 6

/*declaration*/ char s_namfile[kiLG_FILE_NAME+1];   /*Recuperation des parametres */ strcpy(s_namfile, argv[3]);

---

Le 3ème paramètre correspond à /home/rep/toto_20090724_104950_676032

Dans mon fichier .h j'ai ceci :

Code:

---

1 2	#define kiLG_FILE_NAME 80

---

jabbounet :

Je lance mon programme avec dbx et obtiens mon erreur :

Citation:

---

$ dbx ss10_em_build_hdr
Type 'help' for help.
reading symbolic information ...warning: no source compiled with -g

(dbx) run uid pwd /home/rep/toto_20090724_104950_676032

Segmentation fault in strlen.strlen [/lib/libc.a] at 0x90000000003b024 ($t1)
0x90000000003b024 (strlen+0x24) 88ac0000 lbz r5,0x0(r12)

---

Je lance la commande where pour avoir plus d'info :

Citation:

---

(dbx) where
strlen.strlen() at 0x90000000003b024
_doprnt(??, ??, ??) at 0x90000000003068c
fprintf(0x9001000a0004720, 0x110000640, 0x110000598, 0x110000574, 0xfffffffffffff2b2, 0xffffffffffffee3a, 0xffffffffffffea67, 0xfffffffffffe296) at 0x90000000002e638
main(??, ??) at 0x1000009ac

---

Donc le pb serait lots du fprintf ??


La suite du code est :

Code:

---

1 2 3 4 5

fprintf(f_hdr_file, "%s%s %s %s %s %s %s%s\n", "FUNCTION:", "MAILPOST", getenv("TOTO_NODE"), getenv("UID_UNIX"), getenv("PWD_UNIX"), getenv("Pin"), s_parfile, ".ack");

---

Je sais qu'on peut écrire dans le fichier f_hdr_file (ça marche pour d'autres messages) mais dès qu'il s'agit d'écrire la valeur du fameux s_parfile ça plante !!

Je n'ai mis en commentaire que la ligne correspondante au fprintf et relancé le programme : ça va jusqu'au bout.

Code:

---

1 2	reading symbolic information ...warning: no source compiled with -g

---

visiblement ton debugger semble penser que ton exe n'a pas été compilé avec -g

Autrement ici il y'a une aide pour AIX
http://publib.boulder.ibm.com/infoce..._coredump.html

Oh non !!

Je suis désolée, je viens de faire plusieurs tests et il se trouve que lorsque j'exécute :

Code:

---

1 2 3

fprintf(f_hdr_file, "%s%s %s%s\n", "FUNCTION:", "MAILPOST", s_parfile, ".ack");

---

Au lieu de :

Code:

---

1 2 3 4 5

fprintf(f_hdr_file, "%s%s %s %s %s %s %s%s\n", "FUNCTION:", "MAILPOST", getenv("TOTO_NODE"), getenv("UID_UNIX"), getenv("PWD_UNIX"), getenv("Pin"), s_parfile, ".ack");

---

ça fonctionne donc mon pb n'est pas du tout lié à s_parfile ni au code servant à l'alimenter :?

Je vais chercher quelle variable d'environnement pose pb et pourquoi...

Merci à tous pour vos conseils, ça m'a bcp servi notamment à comprendre où se trouvait l'erreur.

Met un point d'arrêt dans fprintf (break in fprintf), et quand tu tombes dessus regarde les arguments du fprintf. Il y en a certainement un qui n'est pas bon (certainement s_parfile).

En passant, ce n'est pas propre de mettre un getenv() directement dans un printf comme tu le fais. Si la variable d'environement n'existe pas, getenv() retourne NULL, et donc printf va déréfencer le pointeur NULL. Sous AIX ça ne devrait pas poser trop de problème parce que tu as toujours un 0 à l'adresse 0, mais c'est quand même une erreur.

Pb résolu :D

Voilà ce que j'ai fait...

1 - Définir les variables :

Code:

---

1 2 3 4 5

char acmm_node[200]; char uid_unix[200]; char pwd_unix[200]; char in_directory[200];

---

2 - Récupérer les paramètres :

Code:

---

1 2 3 4 5

strcpy(acmm_node, getenv("ACMM_NODE")); strcpy(uid_unix, getenv("UID_UNIX")); strcpy(pwd_unix, getenv("PWD_UNIX")); strcpy(in_directory, getenv("IN_DIRECTORY"));

---

3 - Ecrire dans le fichier en utilisant les variables :

Code:

---

1 2 3 4 5

fprintf(f_hdr_file, "%s%s %s %s %s %s %s%s\n", "FUNCTION:", "MAILPOST", acmm_node, uid_unix, pwd_unix, in_directory, s_parfile, ".ack");

---

Donc visiblement en copilation 32 bits je peux directement faire un getenv dans un fprintf mais en 64 bits il faut passer par une variable.

Le mieux étant de toujours passer par une variable ;)

Encore merci à tous pour votre aide.

Cat

Chose à savoir, d'expérience, les archi 64 bits sont plus chiantes et laissent moins bien passer les bétises.... :D

Citation:

---

Envoyé par Cathy

Donc visiblement en copilation 32 bits je peux directement faire un getenv dans un fprintf mais en 64 bits il faut passer par une variable.

Le mieux étant de toujours passer par une variable ;)

---

Je doute fortement que ton problème vienne réellement de là.
A priori, je dirais plutôt que tu as un comportement indéterminé quelque part dans ton code et que, manque de chance, le programme semble fonctionné correctement en 32 bits.
La manipulation que tu as faite a masqué le problème mais ne l'a pas corrigé.

Au passage, getenv() peut renvoyer NULL si la variable n'est pas trouvé. Il faut tester ce cas.

Tu as très certainement oublié d'inclure stdlib.h. Donc getenv() n'a pas de prototype, le compilo suppose que ça renvoie un int, et il passe donc un pointeur foireux (tronqué) à printf.