Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
problème avec malloc
Salut à tous, je bute sur un problème assez bizarre:
Dans une fonction, si je fais
char* s = malloc(12000);
J'ai une erreur de segmentation (core dumped) lors de l'execution. Ca plante sur cette insctruction.
Par contre si je fais
char s[12000];
ou
char* s = malloc(12);
Ca marche
Le problème c'est que j'ai besoin d'un malloc(12000).
Si ça peut aider, j'utilise xubuntu via virtual PC 2004 (avec 128mo de ram)
Merci pour vos réponses
Il n'y a aucune raison 'normale' pour que malloc() s'exécute mal. Par contre il peut y avoir eu quelque chose avant qui a démoli le gestionnaire de mémoire, entrainant un comportement indéfini. (Débordement de tableau alloué, par exemple. Mortel !)Envoyé par cyril_sy
Ensuite, pense à tester le valeur retournée par malloc() avant de l'utiliser : NULL signifie "échec d'allocation".
Enfin, il faut libérer le bloc alloué après usage. (free()).
merci pour ta réponse, oui je pense que le problème vient d'ailleurs.
Quand je n'utilise pas la librairie libxml2, je n'ai pas de problèmes.
Mais je ne pensais pas qu'une librairie puisse affecter malloc.
Dans mon cas, malloc n'a pas le temps de renvoyer NULL, ça plante avant, pendant l'instruction...
A ton avis ça peux venir de la librairie, ou c'est ailleurs dans le code?
Cela risque d'être difficile de t'aider si tu ne nous montres pas un peu de ton code...
tu devrais caster à chaque fois que tu fais une allocation et vérifier s aussi
char *s;
s=(char *)malloc(12000*sizeof(char));
if(s==NULL) return;
C'est vrai que ça serait plus simple si je vous donnais une portion de code. Mais je n'ai aucune idée d'ou peut provenir le plantage, donc je ne peut pas selectionner une portion de code en particulier...
Par contre, je n'ai rien changé au code, et maintenant j'ai cette erreur
*** glibc detected *** ./main: free(): invalid next size (fast): 0x08055608 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb76e58bd]
/lib/tls/i686/cmov/libc.so.6(__libc_free+0x84)[0xb76e5a44]
/usr/lib/libxml2.so.2(xmlDictFree+0xc1)[0xb78922d1]
/usr/lib/libxml2.so.2(xmlFreeDoc+0x1b9)[0xb77f4099]
./main[0x80489d5]
./main[0x8048f31]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb76948cc]
./main[0x80487c1]
Est ce que vous savez ce que ça veut dire?
merci pour votre aide
Vérifier, OK. Mais caster ? Pourquoi faire ?
http://emmanuel-delahaye.developpez....tes.htm#malloc
Pas trop, mais je ne serais pas étonné que tu utilises mal une des fonctions de la bibliothèque XML. Je conseille ceci :
http://emmanuel-delahaye.developpez....tm#cfg_compilo
Si tu vois des warnings, tu les analyses (on peut t'aider) et tu les corrige intelligemment (là aussi, on peut aider...).
merci pour ta réponse.
J'ai compilé avec -Wall -Wextra -O2 -Wwrite-strings -Wstrict-prototypes.
Et je n'ai aucun warning.
Je crois que je vais lire la documentation de la librairie (j'ai utilisé des exemples, que j'ai adapté a mes besoin, sans vraiment lire de documentation).
Je ne suis pas un specialiste des messages de la glibc (loin de la) mais a vu de nez, il y a un free qui se passe mal. Tu dois passer (directement ou via la libxml) un pointeur a free qui n'est pas valide.
* Verifie que tu ne modifies pas les valeurs des pointeurs retournes par malloc et par la libxml,
* verifie que tu ne libere pas deux fois le meme pointeur (une bonne pratique est de mettre le pointeur a NULL lorsqu'il n'est plus valide),
* et enfin verifies que tu n'as pas de debordement de buffer.
Merci pour vos réponses, et désolé, je vous ai fais chercher pour rien
J'ai relu attentivement mon code, et a un endroit, je depassais le bloc mémoire allouée...
par contre le moment ou je dépasse, et celui ou ça plante n'ont rien a voir, je ne pensais qu'une erreur pouvais avoir une telle portée lol
maintenant ça marche.
c'est le principe même des erreurs de mémoire...
Puisque tu vas écrire là où tu n'as pas le droit, à cet endroit-là tout peut arriver : il y a un morceau de code, un morceau de structure, de variable...
Et, à moins de pouvoir être dans le compliateur + dans le loader, aucun moyen de savoir ce qu'il y a derrière une certaine adresse au runtime.
Donc, ça peut arriver la ligne suivante comme 200 routines et 5 heures plus tard...
Grosso modo et pour faire simple[1] :
- Si tu debordes dans une zone memoire ou tu n'as normalement pas acces, ca va planter tout de suite.
- Si tu debordes dans une zone ou ton programme a legitimement acces, il n'y a aucune raison que ca plante tant que tu n'utilise pas cette zone memoire. Et lors de l'utilisation soit tu vas avoir un segfault (comme ici), soit tu vas avoir des resultats errones mais pas de plantage (la valeur d'une ou plusieurs variables a ete modifiee), soit il ne va rien se passer.
D'une maniere generale, il faut enormement faire attention a ces debordement de memoire et privilegier, dans la mesure du possible, les fonctions qui controlent la taille maximale des tableaux.
Il peut etre interessant d'utiliser des superviseurs memoire (valgrind, mss, etc.) lors de la mise au point pour traquer ce genre d'anomalies (ainsi que les fuites memoires, doubles liberations, etc.) qui risque de passer inapercu lors des tests.
[1] Pour faire simple car dans les faits le comportement effectif va dependre de la plateforme et du systeme, des privileges de l'application, des allocateurs memoires utilises, etc.
Le comportement decrit est ce qui est generalement rencontre sur des systemes "grand publics" type PC.
Merci pour le conseil, je viens d'installer valgrind, et j'ai trouvé une autre erreur
Répondre avec citation
Partager