Le 30/08/2009 13:13, Patrick Dupre a écrit :
> On Sun, 30 Aug 2009, Nicolas Morey-Chaisemartin wrote:
>
>> Le 29/08/2009 21:03, Patrick Dupre a écrit :
>>> Bonsoir,
>>>
>>> J'ai attache un fichier genere par valgrind car je suis certain d'avoir
>>> des fuites memoire, mais je ne comprends rien a ce fichier.
>>> Si quelqu'un a des idees !
>>>
>>> Merci
>>>
>>
>> A priori tu n'as pas de fuites mémoires:
>>
>> definitely lost: 0 bytes in 0 blocks.
>> ==10016== possibly lost: 0 bytes in 0 blocks.
>> ==10016== still reachable: 18,927 bytes in 573 blocks.
>> ==10016== suppressed: 0 bytes in 0 blocks.
>> ==10016== Reachable blocks (those to which a pointer was found) are
>> not shown.
>> ==10016== To see them, rerun with: --leak-check=full --show-reachable=yes
>>
>>
>> Il n'y a aucune zone mémoire sur lesquelles tu n'as pas de pointeurs
>> dessus. Il n'y a juste que les 18kb que tu n'as pas libérés avant de
>> sortir mais étant donné que tu as toujours un pointeur dessus, ce
>> n'est pas une fuite a proprement parler.
>>
>
> OK, merci pour le commentaire, mais je reste inquiet. Ce qui ce passe
> c'est que j'ai une application qui envahit toute ma RAM, typiquement
> je pars de 300 Mo et je termine a 3Go.
Donc c'est une surallocation plus qu'une fuite mais je comprends le problème.
> Donc, je comprends que lorsque je quitte l'application la memoire
> est desallouee correctement mais cela ne signifie pas que je controlle
> bien l'allocation.
> Cette application en ecrite en perl. mais la partie qui me preoccupe
> est une procedure de "fit" qui tourne ~ 50 fois est surement c'est elle
> qui est envahissante. Elle fait appel a un package C++ dont la function
> de calcul appel des routines perl.
Essaye d'utiliser l'outil massif de valgrind (valgrind --tool=massif + quelques options dont je ne me souviens jamais).
Ca te donne l'évolution de ta conso mémoire en fonction du temps, donc ca peut déjà donner une idée pour localiser un peu le problème.
> Je ne suis pas un expert, mais j'ai essaye de faire attention aux
> differents appels et d'eviter des oublis de deallocation a supposer
> que je comprends ce qui se passe lors des differents appels.
>
Vérifie aussi que tu détruis tes objet C++, juste liberer les mallocs ne suffit pas toujours ;)
> Donc, est-ce qu'il y aurait un outil qui me permettrait de voir
> quelles variables occupent quelle espace memoire. Cela me permettrait
> de voir ce qui se passe plus finement.
Jamais essayé mais il y a ccmalloc disponible direct par apt-get sous ubuntu.
Nicolas