Erreur *** glibc detected ***free(): invalid pointeur

Erreur *** glibc detected ***free(): invalid pointeur - C - Programmation

Marsh Posté le 19-08-2011 à 11:34:12    

Bonjour à tous,
 
Je suis actuellement en train de recompiler sous Linux (Red Hat5) des programmes compilés initialement sous Unix True64.
Pour l'un d'entre eux j'ai le message suivant à l'exécution alors que la compilation se passe bien :  
 
*** glibc detected *** free(): invalid pointer: 0x00007fffbc5aad90 ***
 
 
Il s'avère dans le programme que j'exécute un free sur une structure, voici mon code :  
 
Définition de la structure :  
 
typedef struct
{
   char   cod_uc[5];
   char * adr_list_sites;
   int    nbr_sites;
} list_uc_sites;
 
 
/*****************************/
 
Dans le programme :  
 
list_uc_sites pUC;
char * ptemp;
int  indUC;
int  lgOCC_UC=0;
 
/* INITIALISATION DE LA STRUCTURE */
 
strcpy(pUC.cod_uc,"" );
pUC.adr_list_sites=NULL;
pUC.nbr_sites=0;*
 
memmove(ptemp+indUC*lgOCC_UC,&pUC, (size_t) lgOCC_UC);
 
/*Je ne mets pas ici l'implementation du pointeur ptemp ni de l'int indUC
 
free(&pUC);
 
Voilà partout où je fais appel à cette structure qui est exécuté par le free
 
Quelqu'un voit-il un problème quelque part sachant que le programme tourne très bien sous true64


Message édité par sal1 le 19-08-2011 à 11:35:19
Reply

Marsh Posté le 19-08-2011 à 11:34:12   

Reply

Marsh Posté le 19-08-2011 à 11:50:16    

tu fais un free sur une variable non allouée par malloc.

Reply

Marsh Posté le 19-08-2011 à 12:43:01    

xilebo a écrit :

tu fais un free sur une variable non allouée par malloc.


 
Lorsque je fais le malloc : pUC = malloc(sizeof(list_uc_sites*));
 
J'ai un message d'erreur à la compilation : " error: incompatible types in assignment"

Reply

Marsh Posté le 19-08-2011 à 12:59:36    

normal , pUC est de type list_uc_sites alors que malloc renvoie un void *.
 
 
Lorsque tu fais list_uc_sites pUC; tu déclares une variable sur la pile de type list_uc_sites  et la mémoire sera libérée à la fin du bloc ( je passe le cas des variables globales ). Donc inutile de faire un free dessus, cela n'a pas de sens.
 
 
Si tu veux allouer dynamiquement ( donc sur le tas ) une structure de type list_uc_sites, il te faut alors déclarer un pointeur sur cette structure et l'allouer avec malloc, puis désallouer explicitement avec free quand tu n'en as plus besoin.
 
Ex :  
 

Code :
  1. list_uc_sites * pUC;
  2. /* allocation */
  3. pUC = malloc ( sizeof ( list_uc_sites ) );
  4. /* utilisation avec l'opérateur -> */
  5. pUC->nbr_sites = 1;
  6. /* désallocation */
  7. free( pUC );
  8. pUC = NULL;

Message cité 1 fois
Message édité par xilebo le 19-08-2011 à 13:00:02
Reply

Marsh Posté le 19-08-2011 à 14:39:01    

Ok c'est parfaitement clair, j'ai donc supprimé le free mais à l'exécution j'ai un core dumped.
J'ai essayé en allouant dynamiquement ma structure (utilisation de malloc et de free) et là aussi j'ai un core dumped à l'exécution
 
Existe-t-il un moyen de savoir quelle variable provoque ce core dumped ?
 
 

xilebo a écrit :

normal , pUC est de type list_uc_sites alors que malloc renvoie un void *.
 
 
Lorsque tu fais list_uc_sites pUC; tu déclares une variable sur la pile de type list_uc_sites  et la mémoire sera libérée à la fin du bloc ( je passe le cas des variables globales ). Donc inutile de faire un free dessus, cela n'a pas de sens.
 
 
Si tu veux allouer dynamiquement ( donc sur le tas ) une structure de type list_uc_sites, il te faut alors déclarer un pointeur sur cette structure et l'allouer avec malloc, puis désallouer explicitement avec free quand tu n'en as plus besoin.
 
Ex :  
 

Code :
  1. list_uc_sites * pUC;
  2. /* allocation */
  3. pUC = malloc ( sizeof ( list_uc_sites ) );
  4. /* utilisation avec l'opérateur -> */
  5. pUC->nbr_sites = 1;
  6. /* désallocation */
  7. free( pUC );
  8. pUC = NULL;



Reply

Marsh Posté le 19-08-2011 à 14:44:22    

tu lances ton programme avec gdb ( penser à le compiler en debug ), et lorsque ça plante , gdb te permet de voir la stack juste avant que ça plante ( commande bt en ligne de commande ). Tu pourras peut-être voir d'où vient ce plantage.
 
Attention, ça ne permet pas de tout debugguer de cette manière, en particulier les écrasements de pile.

Reply

Marsh Posté le 19-08-2011 à 16:12:52    

Je ne connaissais pas gdb c'est vraiment super.
Merci beaucoup j'ai trouvé le problème du core dumped, il s'agissait d'un pointeur sur int non initialisé
 

xilebo a écrit :

tu lances ton programme avec gdb ( penser à le compiler en debug ), et lorsque ça plante , gdb te permet de voir la stack juste avant que ça plante ( commande bt en ligne de commande ). Tu pourras peut-être voir d'où vient ce plantage.
 
Attention, ça ne permet pas de tout debugguer de cette manière, en particulier les écrasements de pile.


Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed