free(): invalid next size (normal)

Version imprimable

29/12/2007, 13h34
Heimdall

free(): invalid next size (normal)

Bonjour,

J'ai un assez gros code de calcul numérique qui me fait un bon plantage. Je l'ai lancé avec gdb histoire d'en savoir un peu plus et celui ci me dit entre autre :

"*** glibc detected *** /home/nicolas/code/hyb2d/bin/001/hyb2d.exe: free(): invalid next size (normal): 0x00000000103e5790 ***"

Je me suis dit, ok ce genre d'erreur c'est classiquement un free() sur un pointeur invalide... cependant le truc étrange c'est qu'il me fait ça à la 15919e itération (qui n'a rien de plus dans son traitement que la 15918e ou la 15920e), donc je me demandais si ce message pouvait signifier autre chose ?

Comme par exemple un dépassement de tableau ou quelque chose comme ça ? En clair, quelles sont toutes les sources possibles en C pour quel mon débugueur me dise ça ?

Bien sûr il ne me dit pas a quel endroit du code c'est arrivé :(

J'ai tenté de lancé mon code avec valgrind pour détecter d'ou venait l'erreur, mais prenant en temp normal environ 4-5h pour arrivé au plantage, un petit calcul me donne environ 3mois pour y arriver avec valgrind vu la lenteur du bazar....

Merci d'avance pour vos pistes et bonnes fêtes de fin d'année
29/12/2007, 15h16
Emmanuel Delahaye

Citation:

Envoyé par Heimdall

J'ai tenté de lancé mon code avec valgrind pour détecter d'ou venait l'erreur, mais prenant en temp normal environ 4-5h pour arrivé au plantage, un petit calcul me donne environ 3mois pour y arriver avec valgrind vu la lenteur du bazar....

Bon, ben rendez vous dans trois mois alors...

Sinon, tu réduis le code au minimum qui provoque le problème (méthode de débogage bien connue) et tu le postes.

Nota : Le débordement de tableau et l'usage de pointeurs non initialisés sont à l'origine de plus de 80% des bugs à l'exécution d'un programme écrit en C.
29/12/2007, 15h18
ram-0000

Oui, cela sent le pointeur fou

plusieurs sources d'erreur:
* double free
* buffer overflow (écriture sur plus que la taille allouée)

Une première approche, lire et relire le code (mais je suppose que tu as déjà commencé ;))

Tu peux aussi rechercher ton problème en créant ta propre surcouche de gestion de la mémoire dynamique qui te fera un controle des paramètres qui incrémentera et décrémentera le compteur d'allocation et qui gardera un historique des blocs alloués et qui a demandé ce bloc

En général, ce genre de librairie ne met pas grand temps à être écrite et est bien utile pour la suite
29/12/2007, 15h23
Heimdall

Salut

Justement, afin de réduire à la portion qui pose probleme, j'aimerais savoir ce que signifie ce message d'erreur... Appremment ça a avoir avec un free(), donc un probleme d'allocation de mémoire.

est-ce la seule source de probleme a envisager ?

Un dépassement de tableau peut-il provoquer ce genre d'erreur ?

EDIT : ok, donc selon vous un dépassement de tableau est possible aussi ?
Je pensais que si tel était le cas le message aurait été segmentation fault non ?
29/12/2007, 15h32
Emmanuel Delahaye

Citation:

Envoyé par Heimdall

Justement, afin de réduire à la portion qui pose probleme, j'aimerais savoir ce que signifie ce message d'erreur... Appremment ça a avoir avec un free(), donc un probleme d'allocation de mémoire.

est-ce la seule source de probleme a envisager ?

Un dépassement de tableau peut-il provoquer ce genre d'erreur ?

EDIT : ok, donc selon vous un dépassement de tableau est possible aussi ?
Je pensais que si tel était le cas le message aurait été segmentation fault non ?

Malheureusement les comportements indéfinis ont, par définition, des comportements ... indéfinis... (Surprenant, non ?) Donc, il est très difficile de prévoir ce qui va se passer ou de tirer des conclusions des comportements visibles.

Il y a un bug dans ton code, et il faut le trouver, c'est tout. Mon petit outil de tracking mémoire

http://emmanuel-delahaye.developpez.com/clib.htm
Module SYSALLOC

peut aider, mais j'ai peur qu'il faille beaucoup de mémoire trace... Tout dépend combien de blocs sont alloués en même temps.

Si le code est bien écrit, il est modulaire et il est facile d'isoler ces morceaux de logiciel.

Si c'est écrit à l'arrache, c'est poubelle et on recommence, mais cette fois, avec méthode, tests unitaires, bref, on fait comme partout dans l'industrie (Architecture, BTP, Auto, Aéronautique etc.), on construit sur des bases solides. Je ne sais pas pourquoi les informaticiens croient pouvoir échapper à ces principes fondamentaux ...

Doivent se croirent plus malins que les autres, ces gonzes...
29/12/2007, 15h43
Heimdall

Indéfini... Ne me dit pas que glibc me dit "free(): invalid next size (normal)" un peu au pif ? Il doit bien y avoir des sources d'erreurs a privilégier et d'autres à laisser de coté en premier lieu...

Donc est-ce que je peux dans un premier temps, écarter les possibles dépassement de tableau pour privilégier les double free() ?
29/12/2007, 16h57
Emmanuel Delahaye

Citation:

Envoyé par Heimdall

Donc est-ce que je peux dans un premier temps, écarter les possibles dépassement de tableau pour privilégier les double free() ?

Non. Tu dois tout vérifier. Je t'ai indiqué un outil pour les allocations...
29/12/2007, 17h23
Heimdall

A quoi sert un message d'erreur de ce type alors ? pourquoi ne pas mettre directement "erreur" s'il faut tout vérifier ?

Désolé d'insister, mais un message d'erreur s'il n'est pas utile pour discriminer quelques sources d'erreurs, ne sert a rien.
29/12/2007, 17h25
Médinoc

Ben justement, ça indique quand est détectée l'erreur (lors d'un free) et que c'est carrément le tas lui-même qui a été corrompu. C'est déjà pas mal...
29/12/2007, 17h40
Heimdall

hum, donc en gros ce qui se passe, c'est que soit je fais un double free() (hautement improbable je pense), soit un free d'un truc pas alloué (improbable aussi) ou alors que mon code écrit en mémoire en dépassant sur un bloc également alloué dans mon processus, et le corompt d'une façon ou d'une autre... ce qui fait que l'appel au free pour ce dernier bloc ne marchera pas ? Ca me semble être la solution la plus rationnelle...
29/12/2007, 20h43
Emmanuel Delahaye

Citation:

Envoyé par Heimdall

hum, donc en gros ce qui se passe, <yap yap yap>

Tant qu'on ne voit pas le code...
29/12/2007, 21h51
Heimdall

Citation:

Envoyé par Emmanuel Delahaye

Tant qu'on ne voit pas le code...

En quoi faire des hypothèses est-il nuisible ?

j'ai rajouté :

Code:

#define free(aa) {printf("[%s][ligne %d] Liberation bloc %s a %p\n",__FILE__,__LINE__,#aa,aa);free(aa);}

Une façon comme une autre de repérer quel free() voit le bug...
29/12/2007, 22h48
PsychoH13

Je voudrais savoir aussi par la même occasion... Comment ça se fait que tu aies 15000 allocations à faire ? (et donc 15000 free).
30/12/2007, 00h05
Heimdall

Euh comment ça comment ça se fait ? J'ai besoin d'allouer des blocs mémoire a chaque itération.... tu dis ça parce que c'est lent ?
30/12/2007, 01h09
PsychoH13

Bah déjà oui c'est plutôt lent, en général on va plutôt allouer par bloc plus large, genre tous 10 t'alloue 10 blocs supplémentaire, ou alors tu alloues 2 fois la taille que tu as précédemment allouée, selon ce dont tu as besoin...

Mais aussi, ce que je veux dire c'est que c'est qu'on de faire des allocations multiple comme ça alors que tu pourrais manipuler qu'un seul pointeur et réallouer la mémoire à chaque itération si nécessaire...

Toujours est-il que dans ton code, il y a un problème qui peut être assez grave, moins tu feras d'allocations intempestives, mieux ce sera.
30/12/2007, 02h11
Emmanuel Delahaye

Citation:

Envoyé par Heimdall

En quoi faire des hypothèses est-il nuisible ?

L'expérience montre qu'essayer d'expliquer les comportements indéfini est une perte de temps. Tu aurais posté ton code, il y a longtemps qu'il aurait été débuggé...
30/12/2007, 11h59
Heimdall

Citation:

Envoyé par Emmanuel Delahaye

L'expérience montre qu'essayer d'expliquer les comportements indéfini est une perte de temps. Tu aurais posté ton code, il y a longtemps qu'il aurait été débuggé...

Ok pour la partie expérience... ensuite pour le post du code c'est niet je n'ai aucune idée de la partie ou ça foire.

Citation:

Envoyé par Heimdall

Ok pour la partie expérience... ensuite pour le post du code c'est niet je n'ai aucune idée de la partie ou ça foire.

Les méthodes classiques de mise au point sont basées sur l'isolation du bug. Evidemment, ça ne fonctionne que si le code est découpé en parties autonomes.

Pour les débordements de tableau, il est aussi possible de 'poser des pièges' sur les indices avec assert() avant chaque accès au tableau :
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 #include <stdio.h> #include <assert.h> int main (void) { int a[10]; int i; for (i = 0; i < 10; i++) /* OK */ { assert (i < 10); /* piege */ a[i] = i * i; } for (i = 0; i <= 10; i++) /* bug */ { assert (i < 10); /* piege */ printf ("%3d", a[i]); } printf ("\n"); return 0; }
Code:

1 2 3 4 5 6 7 0 1 4 9 16 25 36 49 64 81Assertion failed: i < 10, file main.c, line 17 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Press ENTER to continue.
http://emmanuel-delahaye.developpez....tes.htm#assert

Une bonne conception est aussi un gage de réussite, c'est à dire code modulaire, briques autonomes et validées (tests unitaires) etc. La construction logicielle n'échappe pas aux règles de bon sens de l'industrie qui veulent que le code soit construit avec des 'briques' solides, fiables et vérifiées, comme dans n'importe quel domaine industriel (je ne crois pas que le viaduc de Millau ait été construit sur des piles foireuses ou à l'aide de câbles douteux...).

Evidemment, si rien n'a été vérifié ou si rien n'est vérifiable, il n'y a pas grand chose à faire que de poubelliser et de reconstruire sérieusement.

Parfois, cette expérience douloureuse est nécessaire pour redémarrer sur des bases saines. Je me souviens avoir passé une nuit blanche chez un client pour réécrire totalement une portion de code car elle avait été mal conçue au départ et générait tellement de bugs qu'elle était inmaintenable.

De plus, si tu ne veux pas poster le code, je ne vois pas bien comment on peut t'aider plus...

Pour résumer, plutôt que de perdre du temps à débugger du code, mieux vaut écrire du code sans bugs. Si on ne code pas avec ses pieds, mais plutôt avec sa tête, c'est possible.

02/01/2008, 11h25
Heimdall

Pour ceux qui tomberaient sur ce topic suite à une erreur semblable... Mon probleme était l'oubli d'un free() dans ma boucle, suite à quoi une fuite mémoire galopante satura le tout jusqu'à qu'une allocation mémoire ne se fasse plus (non testée) et que le free() correspondant plante.