Discussion :

[jeanmini]

Bonjour,

Je viens demander une petit coup de main j'ai un petit soucis.
J'ai un processus en C qui s'occupe des traitements entre applicatifs et le web et qui possède un démon http.
Celui-ci est propre, du mtrace pendant une heure pas de suites mémoires.
Je le laisse faire la même tache pendant plusieurs heures.

Après 4-5 heures le processus fait la même taille au ko près.

Cependant après plusieurs heures supplémentaires sa taille a doublé (d'un coup semble t'il). donc je ne comprend pas car il n'y a pas eu d'autres appels de fonctions autres que celles qui on été testé avec mtrace.

J'ai remarqué que dans le pmap -x j'ai (après que le processus ai grossit) un 8188ko dans [anon]

Quelqu'un aurait-il une piste ?

En vous remerciant d'avance

[Neckara]

Si tu utilises des pointeurs de pointeurs, il est possible que tu fasses :
free(*x); où *x a déjà été libéré et dont la valeur est indéterminée ?

Ainsi cela peut fonctionner la plupart du temps et ne plus marcher soudainement, après ce n'est qu'un hypothèse.

[jeanmini]

non, je ne pense pas, j'ai déjà pas mal tourner autour du pot. j'ai l'impression que cette allocation ce fais peut-tetre plus bas?

[Neckara]

Je pense qu'il faudrait que tu donnes tes sources, avec une explication de l'architecture.
Je pense que cela sera plus facile aux membres expérimentés de t'aider.

[jeanmini]

Je suis ingénieur dans une entreprise donc bien sur les codes sont privés .. désolé.. Je vois cependant souvent dans les gens qui montrent des pmaps de logiciels souvent ce 8188 dans [anon] donc j'esperait que quelqu'un est une explication, le fait qu'il soit si souvent présent, je pense que c'est le noyau qui l'alloue mais pourquoi? et ou ? :s

[Jean-Marc.Bourguet]

Il y a une série de possibilités. Principalement segment BSS des lib dynamiques et le tas. Il faut chercher dans ton programme. Note que la fragmentation peut expliquer ce genre de comportement, mais j'aurais tendance à chercher d'abord les fuites (et les fuites cachées, la mémoire qui est toujours référencées mais qu'on pourrait libérer parce qu'elle ne sera plus utilisée).

[Obsidian]

Je suis ingénieur dans une entreprise donc bien sur les codes sont privés .. désolé.. Je vois cependant souvent dans les gens qui montrent des pmaps de logiciels souvent ce 8188 dans [anon] donc j'esperait que quelqu'un est une explication, le fait qu'il soit si souvent présent, je pense que c'est le noyau qui l'alloue mais pourquoi? et ou ? :s

Autant que je sache, pmap fait état des segments de mémoire partagée alloués avec mmap et les segments « anonymes », déclarés avec MAP_ANONYMOUS, sont ceux qui ne sont rattachés à aucun fichier propre (à l'image des tubes nommés ou anonymes) et qui, donc, iront dans le swap si nécessaire. Il me semble que c'est la façon « BSD » de gérer la chose.

Donc, il est normal qu'un mtrace() sur les appels à malloc() ne donne rien. Ce qui est plus étonnant, c'est que vérification faite, ça ne semble pas choquer valgrind non plus.

[jabbounet]

Tu peux aussi utiliser un outil de type valgrind ou purify.....
Il y'a la possibilité de le combiner avec un outil d'analyse de couverture de code (gcov) pour voir quel code est executé.



tu peux aussi regarder dans les logs/traces reseau dans la période ou la mémoire a augmenté et comparer avec ce qu'il se passe en temps normal pour essayer de deviner dans quelle partie du code cela se situe.