Re: RE : [Tsp-devel] Increasing memory while sampling

[Eric Noulard]

Le 26/07/07, ALAUX, Virginie<address@hidden> a écrit :
> Re,
>
> Autres réflexions:
>
> 1 - valgrind ne détecte rien si ce n'est les memoryLeaks déjà tracés par le bug 
> 18952 (sur le addParam (TSP_consumer_request_sample))
> => ce qui veut dire qu'en fin de process, tout est bien désalloué

C'est déjà pas si mal :))

> 2 - J'ai fait un stub de tsp_consumer.c : les fonctions tsp_consumer_request_sample_init, 
> tsp_consumer_request_sample_destroy ne font rien et tsp_consumer_read_sample renvoie un 
> sample "en dur".
> => la mémoire reste stable
> Donc c'est bien dans ces 3 fonctions que le problème se pose.

Là je ne suis pas tout à fait d'accord ...
Ces fonctions "à elles seules" ne peuvent pas consommer de la mémoire
jusqu'à plus soif, i.e. activement, vu qu'elles n'ont pas d'activité PROPRE.

Les "seules" fonctions qui peuvent consommer de la mémoire sont
celles qui sont appelées PENDANT la boucle de sampling, soit:

* tsp_consumer_read_sample
 et le thread (interne à la lib TSP)  de réception des samples:
* TSP_request_provider_thread_receiver

Le code de cette fonction est ultra simple puisque c'est une bête
boucle d'appel à:
TSP_data_receiver_receive

jusqu'à la fin des samples (sample_destroy ou fermeture socket).

(sauf erreur de ma part)
Ces fonctions ne font pas d'allocation mémoire mais seulement
des copies vers des zones mémoires déjà allouées.

> 3 - Le fait qu'au 2eme start, la mémoire reste stable peut peut-être indiquer 
> que suffisamment de buffers ont été alloués pendant le 1er sampling et non 
> désalloués...

La principale chose allouée lors d'un sample_init
est le RINGBUFFER utilisé comme une fifo entre le thread TSP de réception
des samples et l'appli user qui fait les read_sample.

l'allocation est faite par un appel à la MACRO
RINGBUF_PTR_INIT
qui n'est utilisée qu'une fois (côté consumer) dans
request_sample_init.

la taille du RINGBUF dépend du nombre de variable
samplées et de leur fréquence, mais elle ne change pas
après le début du sampling.

> Je suis absente jusqu'à lundi...
> Bon week-end à tous!!

Donc j'aimerais pouvoir faire plus mais vu les éléments
que j'ai ça va être difficile :=))

Pourrais-tu faire un essai avec ton provider et
ascii_writer comme consumer?

Peux-tu aussi nous préciser:
- la version de TSP utilisée (et les éventuels patches appliqués)
- le type de machine
  (linux,solaris,OSF, avec version OS et architecture sparc, x86, x86_64 ...)

Je me demande si ce ne serait pas la bufferisation socket du système
qui provoque celà??
Suite à l'appel à acquisitionStart() est-ce que l'application
fait des consumer_read_sample ou pas?

C'est-à-dire des appels à OCEIF_TSP_ScoeComm::readSample ?

--
Erk