Pourquoi est-ce que je reçois cette erreur d’access mémoire ‘double libre ou corruption’?

Je reçois le type d’erreur suivant. Je sais que cela a quelque chose à voir avec mon access incorrect à la mémoire, mais je ne sais pas exactement comment. S’il vous plaît, aidez-moi à voir où je me suis trompé.

* note J’ai simplifié ma fonction et il n’est pas évident de savoir ce que les variables font, j’ai juste besoin de savoir comment je m’implique correctement ou j’utilise mal l’access mémoire.

int my_function(char const *file_name, size_t max) { myStruct.pStore = fopen(file_name,"w+"); //pStore is a FILE* myStruct.max = max; // fill the with zeros ('0') int numberOfZeros = max*SIZE; char zeros[numberOfZeros]; int i=0; while(i<numberOfZeros) // insert zero's { zeros[i]='0'; i++; } fwrite(zeros,sizeof(char),numberOfZeros,myStruct.pStore); fclose(myStruct.pStore); return EXIT_SUCCESS; 

L’erreur qu’on me donne:

 *** glibc detected *** /home/.../: double free or corruption (top): 0x0804c008 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xb7e82e42] /lib/i386-linux-gnu/libc.so.6(fclose+0x154)[0xb7e72384] /home/2012/spatar/cs/specs/release[0x80486b0] /home/2012/spatar/cs/specs/release[0x8048acd] /home/2012/spatar/cs/specs/release[0x8048af0] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb7e284d3] /home/2012/spatar/cs/specs/release[0x80484e1] ======= Memory map: ======== 08048000-0804a000 r-xp 00000000 00:3b 2331829 /home/2012/spatar/cs/Aspecs/release 0804a000-0804b000 r--p 00001000 00:3b 2331829 /home/2012/spatar/cs/specs/release 0804b000-0804c000 rw-p 00002000 00:3b 2331829 /home/2012/spatar/cs/specs/release 0804c000-0806d000 rw-p 00000000 00:00 0 [heap] b7e0e000-b7e0f000 rw-p 00000000 00:00 0 b7e0f000-b7fae000 r-xp 00000000 00:11 5415 /lib/i386-linux-gnu/libc-2.15.so b7fae000-b7fb0000 r--p 0019f000 00:11 5415 /lib/i386-linux-gnu/libc-2.15.so b7fb0000-b7fb1000 rw-p 001a1000 00:11 5415 /lib/i386-linux-gnu/libc-2.15.so b7fb1000-b7fb4000 rw-p 00000000 00:00 0 b7fbc000-b7fd8000 r-xp 00000000 00:11 5426 /lib/i386-linux-gnu/libgcc_s.so.1 b7fd8000-b7fd9000 r--p 0001b000 00:11 5426 /lib/i386-linux-gnu/libgcc_s.so.1 b7fd9000-b7fda000 rw-p 0001c000 00:11 5426 /lib/i386-linux-gnu/libgcc_s.so.1 b7fda000-b7fdd000 rw-p 00000000 00:00 0 b7fdd000-b7fde000 r-xp 00000000 00:00 0 [vdso] b7fde000-b7ffe000 r-xp 00000000 00:11 5405 /lib/i386-linux-gnu/ld-2.15.so b7ffe000-b7fff000 r--p 0001f000 00:11 5405 /lib/i386-linux-gnu/ld-2.15.so b7fff000-b8000000 rw-p 00020000 00:11 5405 /lib/i386-linux-gnu/ld-2.15.so bffdf000-c0000000 rw-p 00000000 00:00 0 [stack] 

    On dirait que vous essayez de libérer de la mémoire déjà libérée ou déréférencée.

    Liez votre programme avec efence ou exécutez-le avec valgrind .

    Cela vous indiquera où votre pointeur est déréférencé.

    La corruption de la mémoire est généralement causée par une écriture dépassant la fin de la mémoire allouée. Il s’agit souvent d’un octet car quelqu’un a oublié d’append un octet nécessaire à la valeur null pour terminer une chaîne.

    Double free signifie que free (x) a été appelé deux fois de suite avec la même valeur de x. Quelque part dans votre code, free (x) est appelé, puis très probablement dans un autre morceau de code, free (x) est appelé à nouveau.

    Le moyen le plus simple d’isoler le problème est d’utiliser gdb et d’observer ce qui se passe lorsque vous parcourez votre code.

    Dans votre code my_function ci-dessus, il n’y a pas d’appels gratuits ou gratuits vers malloc. Le tampon de zéros se trouve sur la stack et la boucle while n’écrit pas au-delà de la fin du tampon. Le problème est dans une autre partie du code. Le temps requirejs pour résoudre le (s) problème (s) dépend du nombre de personnes appelées depuis malloc / free / strdup, etc.