Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2537 connectés 

  FORUM HardWare.fr
  Programmation
  C

  [Resolu] A la quete de '** glibc detected ** free()'

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Resolu] A la quete de '** glibc detected ** free()'

n°1307537
Olivier51
Posté le 16-02-2006 à 23:03:50  profilanswer
 

Je suis actuellement bloqué dans un de mes programmes ... par cette erreur à l'execution ...
*** glibc detected *** free(): invalid next size (fast): 0x0806d768 ***
 
Il plante sur un endroit où il n'y a pas de free() et d'ailleurs, je ne libère pas la mémoire dans cette environ ...
Je me suis dit que ça pouvait venir d'une libération automatique lorsqu'une variable allouée par un malloc ne sera plus utilisée ...
 
Par contre, dans mes sources j'utilise ce genre d'opération, et je ne sais pas si c'est bien ...
char* buffer = (char*)malloc(1000);
(...)
buffer++; (je ne sais pas si ça marche, mais en gros je modifie l'emplacement pointé initialement par buffer)
(...)
et du coup, est-ce que si je fais un free() sur buffer, je ne vais pas avoir une erreur puisque ce n'est pas l'emplacement initiale alloué par malloc()


Message édité par Olivier51 le 17-02-2006 à 19:42:42
mood
Publicité
Posté le 16-02-2006 à 23:03:50  profilanswer
 

n°1307547
skelter
Posté le 16-02-2006 à 23:19:51  profilanswer
 

oui, tu dois donner à free l'adresse retournée par malloc, utilises un autre pointeur pour te déplacer sur la zone allouée
 

Code :
  1. char* buffer = malloc(1000);
  2. if( buffer )
  3. {
  4.     char *p = buffer;
  5.     ...
  6.     p++; /* pas de probleme, tu ne perd pas la valeur de buffer */
  7.     free(buffer); /* p est invalide */
  8. }


 

Citation :


Il plante sur un endroit où il n'y a pas de free() et d'ailleurs, je ne libère pas la mémoire dans cette environ ...
Je me suis dit que ça pouvait venir d'une libération automatique lorsqu'une variable allouée par un malloc ne sera plus utilisée ...


 
ca peut ne pas venir directement de free mais d'une fonction qui appelle free, genre fclose

n°1307573
Olivier51
Posté le 17-02-2006 à 00:51:53  profilanswer
 

Ouais, c'est ce que j'aurais choisi comme alternative si je suis obligé de réutiliser le pointeur intial du malloc.
 
J'utilise la libxml, je pense qu'il peut-etre une des cause du message :
*** glibc detected ***

n°1307588
matafan
Posté le 17-02-2006 à 05:05:21  profilanswer
 

Le message, c'est parce que tu passes a free() un pointeur vers une zone qui n'a pas été allouée par malloc(). Y'a pas à chercher ailleurs.

n°1308294
Olivier51
Posté le 17-02-2006 à 19:12:14  profilanswer
 

Je continue ma quete de cette erreur ... j'ai pu ainsi découvrir des outils, tel que valgrind et electric-fence ...
 
Avec valgrind, je suis à 205 erreurs ... Ils disent que dépasser 100 ereurs, le détails n'est plus affiché
 
Je suis passé à electric-fence ...
 
(...)
printf("ii) %s %s\n",tmp,res);
   strcat(tmp,res);
printf("iii)\n" );
(...)
 
Le programme s'arrete sur le strcat par un SEGFAULT ... le premier printf m'affiche bien tmp=val1 et res=val2
 
La trace de gdb :

(gdb) run
Starting program: /home/olivier/Project/prototype/analyzer/analyzer syntax.xml
[Thread debugging using libthread_db enabled]
[New Thread -1211848064 (LWP 6130)]
 
  Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
i)
ii) val1 val2
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211848064 (LWP 6130)]
0xb7cce4dd in strcat () from /lib/tls/libc.so.6
(gdb) where
#0  0xb7cce4dd in strcat () from /lib/tls/libc.so.6
#1  0x0804b461 in AnalyzerBuilder::translationExpression (this=0xb7b4bfbc, str=0xb7a69ff4 "3%TAG_end%" )
    at AnalyzerBuilder.cpp:119
#2  0x0804b5a4 in Expression (this=0xb7a53ff8, reader=0xb7b8af40, analyzerbuilder=0xb7b4bfbc) at AnalyzerBuilder.cpp:62
#3  0x0804bfc3 in AnalyzerBuilder::processNode (this=0xb7b4bfbc, reader=0xb7b8af40) at AnalyzerBuilder.cpp:31
#4  0x0804c1b1 in AnalyzerBuilder::Parse (this=0xb7b4bfbc, namefile=0xbfdfb9c6 "syntax.xml" ) at AnalyzerBuilder.cpp:46
#5  0x0804912e in main (argc=2, argv=0xbfdfa0c4) at analyzer.c:31
(gdb)


 
Là, je ne vois pas ce qui bloque ..

Message cité 1 fois
Message édité par Olivier51 le 17-02-2006 à 19:14:15
n°1308301
Emmanuel D​elahaye
C is a sharp tool
Posté le 17-02-2006 à 19:22:37  profilanswer
 

Olivier51 a écrit :

(...)
printf("ii) %s %s\n",tmp,res);
   strcat(tmp,res);
printf("iii)\n" );
(...)


Le programme s'arrete sur le strcat par un SEGFAULT ... le premier printf m'affiche bien tmp=val1 et res=val2
Là, je ne vois pas ce qui bloque ..


 
Comment est défini 'tmp' ?
Que contient (ou 'sur quoi pointe') 'res' ?


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
n°1308314
Olivier51
Posté le 17-02-2006 à 19:34:58  profilanswer
 

Effectivement, j'ai pas été assez attentif, mauvaise taille avec le malloc ...
 
Problème presque résolu ... plus que 1 erreur avec valgrind !!!
 
Je recommande beaucoup Electric-fence + gdb à ceux qui aurait des problème de 'mémoire' et qui lirait ce sujet à la recherche de solutions.

n°1308319
Olivier51
Posté le 17-02-2006 à 19:41:42  profilanswer
 

Problème résolu ...
 
Conclusion : mauvaise taille avec le malloc qui ne fait pas planté forcément en cas de dépassement le programme sous Linux.
Solution pour trouver le problème : Electric-fence + gdb

n°1308344
Emmanuel D​elahaye
C is a sharp tool
Posté le 17-02-2006 à 20:37:24  profilanswer
 

Olivier51 a écrit :

Problème résolu ...
 
Conclusion : mauvaise taille avec le malloc qui ne fait pas planté forcément en cas de dépassement le programme sous Linux.
Solution pour trouver le problème : Electric-fence + gdb


Ca, c'est pour réparer... Il vaut mieux se concentrer sur la conception et le codage et ne pas faire d'erreur, ou utiliser des méthodes 'souples' (autodémerdantes). Personnellement, j'ai résolu le problème des chaines avec ce code :  
 
http://mapage.noos.fr/emdel/clib.htm
Module FSTR


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
n°1308346
skelter
Posté le 17-02-2006 à 20:46:05  profilanswer
 

pourquoi on aurait pas dans la bibliothèque standard un type string complexe comme ton fstr ?

mood
Publicité
Posté le 17-02-2006 à 20:46:05  profilanswer
 

n°1308351
Emmanuel D​elahaye
C is a sharp tool
Posté le 17-02-2006 à 21:02:12  profilanswer
 

skelter a écrit :

pourquoi on aurait pas dans la bibliothèque standard un type string complexe comme ton fstr ?


Ca existe dans d'autres langages ...
 
Le C a sû rester simple, mais extensible exactement selon nos besoins. Le contraire d'une usine à gaz à la Java ou C++...


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C

  [Resolu] A la quete de '** glibc detected ** free()'

 

Sujets relatifs
[résolu]Socket non bloquants[résolu]lecture tags id3v2
[RESOLU] problème de condition[resolu] Plugin Visual Editor ne fonctionne pas.
quel est l'adresse d'upload de free ?[VBScript] [RESOLU]création administrateur de domaine
[RESOLU] while (mysql_sql_fetch_array) imbriqués[RESOLU] [VBS] recherche OU d'un utilisateur donné d'Active directory
[Résolu] Probleme listbox + onclick[RESOLU]probleme avec zoom d'image inspiré des portes coulissantes
Plus de sujets relatifs à : [Resolu] A la quete de '** glibc detected ** free()'


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR