Discussion :

[Kalite]

Bonjour,

Je voudrait savoir, un petit chose. Je suis sous un linux embarqué à chaque fois que je créer un thread la VCZ de mon programme augmente de 8192 (Je n'arrive pas à trouver l'unité). Lorsque le thread est détruit la VCZ ne diminue pas.

Il n'y a pas l'air d'avoir de fuite mémoire dans mon programme. Donc je ne comprend pas pas pourquoi ?

Merci d'avance de vos lumière.

[DonQuiche]

Bonjour.

Avant tout le VSZ est exprimé en ko, ton programme a donc vu sa taille augmentée de 8Mo. Voici quelques raisons pour lesquelles la taille ne diminue pas forcément :
* L'implémentation de "free" par la libc ne redonne pas systématiquement les pages libérées au système. La plupart du temps elle les garde sous le coude pour un prochain appel de malloc.
* Une biblio peut avoir été chargée par le thread. Même si celle-ci est partagée avec d'autres processus et n'a donc pas nécessité d'allocation mémoire elle sera tout de même comptabilisée par ps.
* Et, bien sûr, le thread peut avoir créé des données qui n'ont pas été détruites. Ce qui n'est pas une fuite mémoire si ces données sont utilisées par d'autres threads. Oui, j'aime bien faire mon captain obvious.

[Emmanuel Deloget]

De manière générale, les ressources mémoires utilisées par un programme augmentent toujours, et ne diminue jamais. C'est une vision simpliste (cf ci-dessous).

L'implémentation traditionnelle des fonctions d'allocation mémoire utilise l'appe;l système brk() pour réserver de la mémoire en plus pour un process. Il est plus couteux de rendre cette mémoire (qui pourrait nécessiter d'être récupérée ensuite) plutôt que de la garder "au cas ou".

Bien sûr, j'ai dis que c'était une vision simpliste, elle est donc souvent fausse. Les linux récents, lorsqu'ils sont couplés à une libc récente, utilisent l'appel système mmap pour réserver de la mémoire pour les grosses allocations. Si cette mémoire n'est plus nécessaire, la rendre au système est tout à fait envisageable. Evidemment, il faut que la libc utilisée utilise cette technique pour que ça soit efficace ; dans le cas contraire, on en revient à brk().

Pour ton "problème" de VSZ, cf. http://virtualthreads.blogspot.com/2...-on-linux.html (ou tu apprendra que ce nombre, au final, ne veut pas dire grand chose).

[Kalite]

Merci pour les infos. J'avai déjà lu que la VCZ ne signifiait pas grand chose. Mais quand même voir la taille augmenter de 8192ko a chaque nouveau thread sa fait bizarre car je ne fait aucune allocation dynamique au delà de 1024o.

Ce pourrait-il que ce soit la pile du thread qui soit alloué a chaque fois ?

[DonQuiche]

Par défaut, sous Linux, la taille de la pile est effectivement 8Mo (peut changer selon les systèmes) mais elle est de toute façon libérée lorsque le thread se termine (mais, là aussi je présume, pas forcément redonnée au système). Es-tu certain que la mémoire augmente systématiquement à chaque fois que tu détruis un thread et en recrée un autre ? Je t'invite à faire un test rigoureux avec N fermetures et ouvertures, je gage qu'au bout d'un moment la mémoire n'augmentera plus.

[Kalite]

Je remonte le post car j'ai de nouveau élément. En effet, il semble qu'au bout de + ou - 250 connexions je n'arrive plus à lancer de thread. La valeur de blocage est la même dans top. Je n'ai fait que 2 fois le test.

Voici le retour de la commande "top":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
  PID  PPID USER  STAT   VSZ %MEM %CPU COMMAND
  965   962  root     R     2252   8%      1% top
  634     1   root     S     2027m7032%  0% MyApp
 
et le retour de la commande "free":
                  total         used         free       shared      buffers
Mem:        29508        16876        12632        0              0
Swap:           0              0              0
Total:        29508        16876        12632

Je suis entrain de faire des tests supplémentaire pour être sûr mais il me manque la première la trace qui est au début de la routine du thread.

Edit : la fonction pthread_create retourne EAGAIN à partir du 253ème. J'utilise la fonction pthread_cancel pour terminer le thread si besoin mais je n'appel aucune fonction lorsque le thread se termine tout seul en retournant 0 sytématiquement.

[Kalite]

J'ai trouvé !!

C'est simle faut juste bien lire la doc. Il est indispensable de faire un pthread_join() pour que l'ID et la stack du thread soit réutilisable.