Localiser précisément un dépassement de mémoire

Hello!

Bon voila, j'ai en ce moment le genre de problème un peu mystérieux pour moi, enfin en tout cas difficile a régler. Récemment j'ai posté un sujet similaire, sauf que l'erreur s'est en fait révélée assez bidon...

Bref mon problème en ce moment est que je doit avoir dans mon programme une erreur qui aboutit a la lecture ou a l'écriture dans des endroits de la mémoire ou j'ai pas le droit, et un segfault apparait donc naturellement a divers moments..

Ma question est simple: y'a t-il un moyen de stopper le programme, ou de signaler l'instruction exacte, au moment précis ou il y a un quelconque dépassement?

----

Je décrit brièvement le comportement quand même, le but étant simplement de bien poser problème et non que vous m'aidiez a débugger (le programme étant trop long, et je n'ai pour le moment aucune idée de l'endroit qui peut poser problème). Ma fonction:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void write_pdb_atoms(FILE *f, s_atm *atoms, int natoms) { s_atm *atom = NULL ; int i ; for(i = 0 ; i < natoms ; i++) { atom = atoms + i ; fprintf(stdout, ">> Atom %p: %d vs %d\n", atom, i, natoms) ; fflush(stdout) ; fprintf(stdout, "%s %d \n", atom->type, atom->id) ;   write_pdb_atom_line(f, atom->type, atom->id); } }

---

En gros, si je met le deuxième fprintf en commentaire, j'ai droit a un segfault avec l'affisage suivant (gdb):

Citation:

---

(...)
>> Atom 0x81329c8: 1738 vs 2973
>> Atom 0x36333830: 14388 vs 2973 // Notez que la valeur de i change complètement... de 1738 a 14388
Program received signal SIGSEGV, Segmentation fault.
write_pdb_atoms (f=0x80d6088, atoms=0x810d458, natoms=2973) at src/writepdb.c:106
106 write_pdb_atom_line(f, atom->type, atom->id)
(gdb) where
#0 write_pdb_atoms (f=0x80d6088, atoms=0x810d458, natoms=2973) at src/writepdb.c:106

---

Si en revanche j'execute bien le deuxième affichage, pas de soucis, pas de segfault...

Merci d'avance ;)

tu peux utiliser valgrind, il est parfait pour trouver les failles mémoires.

Code:

---

1 2	valgrind --leak-check=yes ./tonprog

---

A mon avis sur cet ligne ton compilateur dois te signaler une erreur déjà :

Code:

---

fprintf(stdout, ">> Atom %p: %d vs %d\n", atom, i, natoms)

---

T'essayes d'écrire des entiers alors que tu donne des pointeurs sur ta structure s_atome.

Heu arretez moi si jdis une connerie

Citation:

---

Envoyé par apesle

tu peux utiliser valgrind, il est parfait pour trouver les failles mémoires.

Code:

---

1 2	valgrind --leak-check=yes ./tonprog

---

---

Allons-y alors...

@raf: Le format %p permet d'afficher une adresse ;) donc pas de problème là dessu.

et sinon si tu es sur unixoide ddd

Tu peux également utiliser la bibliothèque Electric Fence qui place chaque zone mémoire allouée par malloc() directement avant une page mémoire inaccessible. De cette manière, la faute de segmentation intervient au premier débordement et l'erreur est ainsi plus facile à localiser. Par exemple, le débordement de tableau observé dans le code ci-dessous n'est (chez moi) pas suffisant pour entraîner une erreur de segmentation:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

#include <stdio.h> #include <stdlib.h>   int main(void) { int *p = NULL;   p = malloc(10 * sizeof *p); if (p != NULL) { int i;   /* -tc- ATTENTION: ce code est (volontairement) faux. Debordement   de tableau*/ for (i = 0; i < 30; i++) { p[i] = i; }   for (i = 0; i < 30; i++) { printf("%d ", p[i]); } printf("\n"); }   return 0; }

---

Lorsque que je lie Electric Fence au projet (avec -lefence) l'erreur de segmentation intervient immédiatement dès que j'essaie d'accéder à p[10]. Il est dès lors facile, à l'aide de gdb, de localiser la ligne exacte responsable de l'erreur de segmentation.

Thierry

Trés bien ca! J'ai réussi a régler mon problème avec valgrind, même sic 'était pas évident, un bon nombre d'erreur que je ne comprenais pas trop (des histoires variables non initialisées notamment...).

Bref je vais regarder cet outil également qui me semble plutôt pas mal. MErci bien!