Discussion :

[seb9999]

Bonjour je me permet de poster un petit morceau de code pour illustrer un probleme de core dump que je n'explique pas.

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
class A
{
    public:
    A(){ ptr[0] = (char **) calloc(100, sizeof(char*)); } // reserve 100 slots
 
    ~A(){
        printf("destructor\n");
        for ( int idx = 0; idx < 100; ++idx )
            printf("ptr[0][%d] = %x\n", idx, ptr[0][idx] );
        ptr[0][0] = 0;
        ptr[0][1] = 0;
        for ( int idx = 0; idx < 100; ++idx )
            printf("ptr[0][%d] = %x\n", idx, ptr[0][idx] );
        free( ptr[0] ); // core dump !
      }
 
    char empty[300];
    char** ptr[10];
    int empty2[320];
};
 
 
int main() {
 
    char * string1 =  (char *) malloc( 6 * sizeof(char) );
    char * string2 =  (char *) malloc( 6 * sizeof(char) );
 
    {
        A a;
 
        // some string
        memcpy ( string1, "Hello", 6 );
        memcpy ( string2, "World", 6 );
 
        a.ptr[0][0]= &string1[3];
        a.ptr[0][1]= &string2[1];
 
        printf("<%s>\n", a.ptr[0][0] );
        printf("<%s>\n", a.ptr[0][1] );
 
        // here we overlap string1, but volontary over sized too
        memcpy(a.ptr[0][0], "tes laitues sechent-elles ?", 28 );
 
        printf("<%s>\n", string1 );
        printf("<%s>\n", a.ptr[0][0] );
 
    } // here core dump after destructor call
 
//      free(string1);
//      free(string2);
 
//  exit(0);
}

il y a ecrasement memoire ici

Code :

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

memcpy(a.ptr[0][0], "tes laitues sechent-elles ?", 28 );

si cette ligne est commentee alors tout est OK.

Mais vous pouvez voir dans le destructeur les pointeurs ptr[0][0] et ptr[0][1] sont forces a 0.
Donc j' aimerais savoir comment le programme plante sur le free() du destructeur !. C est comme si il essayait de liberer la ressource de string1 alors qu il n a plus l'addresse pour y acceder.
Voici la pile d appel:

Code :

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

1
2
3
4
5
6
7
8
9
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d19770 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d1aef3 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7d4ed0b in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7d568bd in mallopt () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7d56a44 in free () from /lib/tls/i686/cmov/libc.so.6
#6  0x080489c0 in ~A (this=0xbfa020e8) at test2.cpp:21
#7  0x08048878 in main () at test2.cpp:52

Merci.
-Sebastien.F

[jobherzt]

je ne suis pas un specialiste, mais je dirais qu'il y a un vieux melange C/C++ qui n'est pas forcement terrible :-) tous ces malloc, calloc, memcpy, char *, printf au milieu d'une classe ca fait drole..

pour ta question, je te fais une reponse de normand : en C++ tu as un type chaine de caractere, utilise le, c'est plus propre et ca t'evitera ce genre de deboires.

[edit] et pas de free en C++, on utilise new et delete !

[poukill]

Je suis d'accord avec jobherzt...
Utilise std::string à lea place de char *, et std::vector pour les tableaux...
Ce qui pourrait donner :

Code :

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

1
2
3
4
5
6
 
A()
{
       std::vector <std::string> ptr;
       ptr.reserve(100);//pas obligatoire ici mais bon....
}

Ce qui je pense, permet de bien mieux gérer la mémoire....

[seb9999]

Merci pour vos conseils.
J aimerais pourvoir refortorer mon code avec les container STL comme vous le dites. Mais ceci est un programme d'example soutire d'un autre plus gros et pas beau. Je n'ai malheureusemet pas le temps de refaire le design necessaire.
Je voudrais juste comprendre ce qu il se passe dans le free() avec un debordement memoire.

J'ai encore encore simplifie le programme et il devient complement C.
La thread peux se poursuivre ici :
http://www.developpez.net/forums/sho...d.php?t=289181