Discussion :

[vinzzzz]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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):

(...)
>> 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

[apesle]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[-Raf-]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[vinzzzz]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[souviron34]

et sinon si tu es sur unixoide ddd

[Thierry Chappuis]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[vinzzzz]

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!