Bonsoir a tous, je déteste free , sans free sa marche impec ^^

mais lorsque j'essaye de free sa plante!!

j'ai un paragraphe énorme je comprend pas pourquoi

int malloc_options(t_map *m, int i)
{
int a;

a = 0;
if ((m->options = malloc(sizeof(int *) * i + 1)) == NULL)
return (-1);
while (a != i)
{
if ((m->options[a] = malloc(sizeof(int) * 1)) == NULL)
return (-1);
a++;
}
m->options[i + 1] = NULL;
return (0);
}

pour free je fais

void tab(int **tab){
int i = 0;
while (tab[i] != NULL)
{
free(tab[i]);
i++;
}
free(tab);
}

message d'erreur ..

• • Error in `./a.out': free(): invalid next size (fast): 0x0000000001662700 ***
  • Error in `./a.out': corrupted double-linked list: 0x00000000016626f0 ***

Inconsistency detected by ld.so: dl-open.c: 220: dl_open_worker: Assertion `_dl_debug_initialize (0, args->nsid)->r_state == RT_CONSISTENT' failed!
(boss-88)./a.out 5

• • Error in `./a.out': free(): invalid next size (fast): 0x000000000212e700 ***
  • Error in `./a.out': corrupted double-linked list: 0x000000000212e6f0 ***

Inconsistency detected by ld.so: dl-open.c: 220: dl_open_worker: Assertion `_dl_debug_initialize (0, args->nsid)->r_state == RT_CONSISTENT' failed!
(boss-89)./a.out 5

• • Error in `./a.out': free(): invalid pointer: 0x0000000000e4b6b0 ***

======= Backtrace: =========
/lib64/libc.so.6(+0x7410f)[0x7fd28694010f]
/lib64/libc.so.6(+0x7996e)[0x7fd28694596e]
/lib64/libc.so.6(+0x7a647)[0x7fd286946647]
./a.out[0x401658]
./a.out[0x4015ef]
./a.out[0x400772]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fd2868
edbe5]

./a.out[0x400609]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:07 526935 /home/test/a.out
00601000-00602000 r--p 00001000 08:07 526935 /home/test/a.out
00602000-00603000 rw-p 00002000 08:07 526935 /home/test/a.out
00e4b000-00e6c000 rw-p 00000000 00:00 0 [heap]
7fd2866b6000-7fd2866cb000 r-xp 00000000 08:05 397836 /lib64/libgcc_s.so.1
7fd2866cb000-7fd2868ca000 ---p 00015000 08:05 397836 /lib64/libgcc_s.so.1
7fd2868ca000-7fd2868cb000 r--p 00014000 08:05 397836 /lib64/libgcc_s.so.1
7fd2868cb000-7fd2868cc000 rw-p 00015000 08:05 397836 /lib64/libgcc_s.so.1
7fd2868cc000-7fd286a71000 r-xp 00000000 08:05 393227 /lib64/libc-2.18.so
7fd286a71000-7fd286c71000 ---p 001a5000 08:05 393227 /lib64/libc-2.18.so
7fd286c71000-7fd286c75000 r--p 001a5000 08:05 393227 /lib64/libc-2.18.so
7fd286c75000-7fd286c77000 rw-p 001a9000 08:05 393227 /lib64/libc-2.18.so
7fd286c77000-7fd286c7b000 rw-p 00000000 00:00 0
7fd286c7b000-7fd286c9b000 r-xp 00000000 08:05 395138 /lib64/ld-2.18.so
7fd286e79000-7fd286e7c000 rw-p 00000000 00:00 0
7fd286e98000-7fd286e9a000 rw-p 00000000 00:00 0
7fd286e9a000-7fd286e9b000 r--p 0001f000 08:05 395138 /lib64/ld-2.18.so
7fd286e9b000-7fd286e9c000 rw-p 00020000 08:05 395138 /lib64/ld-2.18.so
7fd286e9c000-7fd286e9d000 rw-p 00000000 00:00 0
7fff1f584000-7fff1f5a5000 rw-p 00000000 00:00 0 [stack]
7fff1f5fe000-7fff1f600000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted

void free_tab(int **tab){
int i = 0;
while (tab[i] != NULL)
{
free(tab[i]);
tab[i] = NULL;
i++;
}
free(tab);
tab = NULL;
}

j'ai essayé avec celle de developpez.com et sa me plante toujours

c'est ma fonction free qui déconne :/ quelqu'un a un exemple a me montrer svp

c'est pas forcement la fonction free qui deconne. Si tu ecris en dehors du tableau par erreur tu peux alterer le comportement de free fourni par le systeme.

Fais tourner ton code dnas un analyseur de memoire comme valgrind.

Aussi tu peux vouloir lire: http://erik.deblan.org/blog/index.php?article13/c-que-faire-en-cas-de-segmentation-fault

je sais pas me servir de valgrind ... lorsque je l'utilise je ne comprend pas du tout les invalid read of size 8 or invalide read of size 8

a chaque debut de boucle je malloc le meme double tableau d'int **

puis a la fin si je tente un free sa explose...

pourtant lorsque je free mes char ** sa marche mais pour les int ** sa merde du coup je free pas

Basiquement ce que fait valgrind est qu'il traque ce qu'il se passe dans la memoire. "invalid read of size 8" veut dire que tu lis 8 octets (un pointeur probablement) a une addresse qui n'est pas cense etre utilise. "invalid write of size 8" veut dire que tu ecris 8 octets a une addresse qui est invalid.

Si tu compile le code en -O0 -g. valgrind peut te dire quel ligne de code C cause cet lecture/ecriture invalide.

A noter que si free fait planter le programme... C'est probablement que le code en lui-même a un problème. Dans ce cas, l'appel à la fonction free qui fait planter te permet de localiser un bug silencieux, sans ça ce bug aurait pu passer inaperçu et causer des problèmes bien plus tard.

Il ne faut donc pas cracher sur free comme ça (sauf si tu as des problèmes d'abonnement...) : ce n'est pas parce qu'un code fonctionne qu'il est forcément correct et sans bug !!!

ok merci je vais essayer de corriger ce bug,

j'ai juste un petit warning que je ne comprend pas cette fois si

alloc_lab.c 41:47: warning: pointer of type ‘void *’ used in arithmetic

int **tab_pos(int size_tab)
35 │ {
36 │ int **tab;
37 │ int i;
38 │
39 │ tab = NULL;
40 │ i = 0;
41 │ if ((tab = malloc(sizeof(int*) * size_tab) + 1) == NULL) // c'est la que j'ai le warning je vois pas du tout pourquoi
42 │ {
43 │ my_putstr("tab_pos fail\n");
44 │ return (NULL);
45 │ }
46 │ while (i != size_tab)
47 │ {
48 │ if ((tab[i] = malloc(sizeof(int) * size_tab)) == NULL)
49 │ {
50 │ my_putstr("tab pos fail\n");
51 │ return (NULL);
52 │ }
53 │ i++;
54 │ }
55 │ tab[i] = NULL;
56 │ return (full_zero(tab, size_tab));
57 │ }

Tu fais un calcul sur le pointeur. Tu prends le pointeur, tu fais +1 et tu le compares ensuite à NULL, ce qui renverra toujours faux puisque NULL vaut 0.

ah merci! j'ai enfin réussi a enlever ce warning,

une petite question , si je ne free pas est ce que la mémoire alloué ce libère automatiquement? après que le programme soit terminer.

Normalement, oui, car les OS gèrent proprement leurs ressources.

Mais ça reste une bonne pratique de le faire manuellement dans le code même s'il n'y a, en théorie, pas strictement besoin de le faire. Ca évite les problèmes en cas d'OS mal conçu ou défectueux, en cas d'imprévus (toujours prévoir l'imprévu est une bonne règle de conception, bien que difficile à appliquer), de modification de code ultérieure, de code mal écrit, etc.

Il n'y a pas de raison valable qui ferait qu'on ne libère pas, dans le code, la mémoire allouée dynamiquement.

En effet, manager proprement la memoire permet de detecter des tonnes de bugs dans la logique du code.