Je ne comprends pas pourquoi la fonction free() considère cette adresse comme invalide. Mais c'est un appel à la fonction malloc() qui me l'a retourné.
 
Dans le programme j'alloue une variable ("ea->lignes" ), de type "lEA*", un pointeur sur une structure. La taille allouée est de 1 372 012 octets (5623 fois la structure) et j'obtiens comme adresse : 0x40318008. Le traitement continue est au moment de libérer la mémoire à l'aide de la fonction free() j'obtiens le message suivant : "free(): invalid pointer 0x40318008!". Le programme se termine normalement. Pendant l'exécution la zone mémoire est bien allouée, je fais des calculs et un affichage et il y a aucun problème.
 
J'ai pensé que je liberais la strcuture plus d'une fois mais ce n'est pas le cas, et j'ai vérifié tout le code. Quand je fais appel à la fonction free() je vérifie que le pointeur n'est pas NULL et après l'appel de la fonction free() je positionne le pointeur à NULL.
 
Est-ce que quelqu'un aurait une explication ?
OS : Linux wh11686 2.4.23 #1 lun déc 29 10:39:32 CET 2003 i686 GNU/Linux
Compilateur : gcc 3.3.4 (Debian 1:3.3.4-6sarge1)
 
La variable ea est déclarée en static dans la fonction nom_de_la_fonction1 qui initialise la structure. La zone mémoire sera allouée dans la fonction nom_de_la_fonction2. La zone mémoire sera finalement liberée dans la fonction nom_de_la_fonction1.
 

1) utilise efence
2) utilise valgrind
3) ça sent le double free ou la corruption massive

Ah oui valgrind, je l'avais oublié celui-là ! Je ne pense pas que ce soit un double free. Qu'est que tu veux dire par "corruption massive" ?

bah si t'as un truc dans le décor mais là où il faudrait pas, tu peux te tapper des heap overflow ...

Voilà j'ai utilisé valgrind et j'obtiens ça :

Et comme par hasard la zone mémoire que j'ai allouée fait la même taille. Qu'est ce que veut dire ce message ? C'est un warning ?

et sur cette exécution 0x1C531020 était la valeur de ea->lignes ?

D'après gdb, ce n'est pas la bonne valeur. C'est 0x40318008. Il va falloir que je refasse des tests demain (je ne suis plus au bureau). Au moment où valgrind affiche cet avertissement c'est la première fois que j'alloue la variable et à ce moment là (juste avant) elle est positionné à NULL.

tu peux utiliser les techniques d'empoisonnement pour vérifier que tout est bien initialiser. plutot que de mettre NULL, tu peux y foutre 0xdeadbeef

 
Euh, tu ne veux pas donner la sortie intégrale de Valgrind ? Parce que là, j'ai l'impression que tu as tronqué le message, ce qui ne va pas nous aider.
 
Taz> Ce 0xdeadbeef me rappelle vaguement qq chose, mais je ne me souviens plus trop quoi. Tu peux rappeler cette technique ?

deadbeef ==> Dead Beef (viande morte) en english, c est un pattern de byte
moins aleatoire que NULL qui te permet de voire ds les debug le spointeurs qui foirent.
 
0xbada110c est pas mal aussi ^^

J'ai trouvé (la trace de valgrind était plus claire cette fois-ci) !!!
En fait c'est tout con et c'est tout simplement dû à un copier/coller non modifié.
 
Dans un cas je dois réaliser un calcul sur une seule ligne du tableau et dans un autre sur toutes les lignes. Donc j'avais une variable qui me donnais le numéro de ligne à traiter ou -1 pour indiquer qu'il fallait faire toutes les lignes.
 
Et dans la partie où je devais modifier toutes les lignes, j'avais laisser traîner ma variable qui valait alors -1. Donc le programme devait mettre à jour la case -1 du tableau.
 
Si ce n'est pas clair, voilà un exemple (chercher l'erreur) :

Avec un PC sous Linux ça "passe" en revanche avec une station Sun sous Unix, ça ne passe pas : "Bus Error(coredump)".

t'es sur que t'as pas des merdes d'alignement ? sous Linux, fais tourner dans valgrind

La seule erreur que m'a signalée valgrind en dehors de ce problème, c'est qu'une variable n'est pas initialisée alors qu'elle est utilisée pour un test. Mais cette variable est initialisée dans une fonction juste avant le test mais valgrind ne le "voit" pas.

ça coredump à quel endroit sur sparc ?

 
Je pige pas pourquoi tu as besoin de passer deux fois tab[index].lapin à ta fonction, une fois par valeur, l'autre par référence. Je ne sais pas ce qu'elle fait, mais ça me parait un peu bizarre. Par pur réflexe, j'éviterais cela. A mon avis, tel quel, il y a des chances pour que le comportement soit indéfini.
Que se passe-t'il si tu passes par une variable intermédiaire ?, du genre :
faire(tab[index].lapin, &temp);  
tab[index].lapin = temp;

[Résolu] ?

Je sais pas, j'ai rien compris. Je crois que darkoli essaye de nous dire qe dans son code, on peut tomber dans un branchement où index < 0, et donc tab[index] explose, il aurait du y avoir tab[i] à la place, ou un truc comme ça. Ceci dit, son code, je le sens pas.

Oui c'est ça. En fait dans un cas je dois réaliser un traitement pour toutes les lignes d'un tableau mais de temps en temps je dois appliquer ce même traitement à une seule des lignes du même tableau.
 
Pour savoir ce que je dois faire j'utilise une variable qui me donne le numéro de la ligne (entre 0 et taille-1). Si cette variable vaut -1 je dois traiter toutes les lignes.
 
Mais je me suis inspiré du code que j'utilisais pour le traitement d'une seule ligne pour réaliser le traitement de l'ensemble des lignes. Et comme un boulet j'ai laissé cette variable (qui valait -1) au lieu d'utiliser le compteur.
 
Oui c'est résolu !

Oui c'est vrai mais c'est une fonction présente dans une des bibliothèques qu'on utilise au boulot et c'est assez compliqué d'aller la modifier. Cette fonction a toujours bien fonctionné même si la façon dont on l'utilise n'est pas très propre !!! (Je vais vérifier lundi !!!)