Newsgroup: it.comp.os.linux.development
Titolo: [Q]: consumo memoria

salve a tutti,
c'è qualche applicazione che mi permette di vedere a runtime in che modo 
un'applicazione sta allocando memoria, quali funzioni lo fanno? ho 
un'applicazione che funziona 24h al giorno e in teoria dovrebbe essere 
sempre attiva, ma lentamente col passare delle ore, arriva a consumare 
tutta la memoria fisica, rallentando il sistema e rendendo necessario un 
riavvio? è scritta in C++ e usa QT come libreria grafica.
grazie a tutti in anticipo
-- 
MSN: sirpsycho_78 -at- hotmail dot com
the last action hero... 
http://tinyurl.com/bgy5w

 modo un'applicazione sta allocando memoria, quali funzioni lo fanno?
valgrind?
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy              ROT13: 
ybe...@cq.vasa.vg

 
l'avevo provato ma rallenta l'applicazione in una maniera orripilante e, 
  considerato che la stessa prevede parecchi timeout, il comportamento 
in fase di debug risulta troppo differente da quello normale. Qualcosa 
di pià snello non c'è?


 Qualcosa di pià snello non c'è?
Forse ce la fai con DUMA, l'erede di Electric Fence, e impostando la
variabile d'ambiente DUMA_SHOW_ALLOC.
http://duma.sourceforge.net/
Chiaro che lo scopo principale di DUMA è un altro (rilevamento degli
accessi non legittimi alla memoria), però se hai il sospetto che ci sia
un leak intorno ad un certo punto puoi restringere la ricerca
(guarda la sezione MEMORY LEAK DETECTION del README).
-- 
  |   \    \  | ___|_  |_  |  ianezz a casa sua... :-)
  |  _ \  | \ | _|    /   /   Verba volant, scripta
 _|_/  _\_|  _|____|___|___|  manent, data corrupted

 
http://duma.sourceforge.net/
darò sicuramente un'occhiata, intanto vi ringrazio!


 
Qui c'e' un articolo interessante
http://www.linuxjournal.com/article/6556
Tuttavia io mi sono trovato bene con LeakCheck, che non e' menzionato 
nell'articolo
http://www.andreasen.org/LeakTracer/
Ciao

magari non interessa più a nessuno, ma il problema si è risolto da solo! 
io compilavo il sorgente su una macchina ed utilizzavo l'eseguibile su 
un'altra (cmq con la stessa versione di S.O., RedHat 7.2), compilando 
direttamente sulla macchina finale il problema è sparito.
Grazie comunque a tutti per le risposte.


 direttamente sulla macchina finale il problema è sparito.
Uguali del tutto? Neanche un pacchetto diverso? Le librerie GTK e le tue 
librerie sono proprio le stesse?
 F

 librerie sono proprio le stesse?
Ciao a tutti,
 chiedo scusa per questa mail che non c'entra col contesto ... ho fatto 
confusione tra i thread :-)
Perdonatemi!
 Ciao
 Federico

 grazie a tutti in anticipo
Ciao.
Prova "pmap -x <pid>". Questo comando ti mostra come la memoria del processo
è suddivisa in text, data, bss, heap e stack. Ti da la stessa mappatura
anche per tutte le librerie condivise. Ovviamente lo spazio stack usato
dalle librerie è lo stesso del programma main del processo e lo trovi in
fondo alla lista.
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 
ti ringrazio per l'interessamento. Ma fa parte di qualche pacchetto? 
nella mia distro non c'è pmap, c'è pmap_dump ma mi sembra serva a 
tutt'altro..
-- 
MSN: sirpsycho_78 -at- hotmail dot com
"Arditi, com'altro nomare questi baldi fiori del regime che osarono 
porre un imperativo categorico tra le sabbie bolsceviche di Marte."

 tutt'altro..
Se non ricordo male fa parte del pacchetto "procps".
Prova ad installarlo, se dovesse mancare fammi sapere cosě cerco meglio da
quale pacchetto me lo sono ritrovato.
Ciao,
