Discussion :

[Heimdall]

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

[Emmanuel Delahaye]

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.

[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

[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 ?

[Emmanuel Delahaye]

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

[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() ?

[Emmanuel Delahaye]

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

[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.

[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...

[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...

[Emmanuel Delahaye]

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

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

[Heimdall]

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

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

j'ai rajouté :

Code :

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

#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...

[PsychoH13]

Je voudrais savoir aussi par la même occasion... Comment ça se fait que tu aies 15000 allocations à faire ? (et donc 15000 free).

[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 ?

[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.

[Emmanuel Delahaye]

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é...

[Heimdall]

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.

[Emmanuel Delahaye]

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 :

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

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

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.

[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.