Newsgroup: it.comp.lang.c++
Titolo: probabile memory leak?

Ho un'applicazione che normalmente alloca intorno ai 50MB di memoria totale
In seguito ad alcune ultime modifiche la memoria allocata sale gradualmente 
e nel giro di qualche ora arriva a toccare i 250MB per poi di colpo tornare 
ai canonici 50MB
Quello che differisce dalla versione precedente è che in alcuni punti il 
programma apre dei files wave, li suona e poi li richiude
Lo schema generale della funzione che fa sta cosa è:
1) apro gli n file mettendo gli handle in un array
2) passo l'array di handle ad un funzione che fa il play
3) chiudo i file liberando gli handle
Io sospetto che qualche close fallisca e che uscendo dalla funzione l'array 
che contiene gli handle venga distrutto mentre resti appeso il riferimento 
al file non chiuso da qualche parte e la memoria cresce
Poi ad un certo punto il buon vecchio winzozz si renderà conto di avere 
allocata memoria inutile e corregge
Mi potete confermare che questo potrebbe essere il problema o devo cercare 
altrove?
-- 
_________________________________________
Edmondo Di Tucci snar...@Tlibero.it
guarda i miei lavori su: 
www.powernetsi.it/edmondo
 

 [CUT]
Se fosse un memory leak, non torneresti ai 50MB, ma resteresti ai 250. 
Molto piu' probabilmente, Windows usa (come molti sistemi operativi) una 
politica lazy per quanto riguarda l'allocazione e liberazione della memoria.
-- 
Mat/tia Belletti - Undergraduate student @ 
cs.unibo.it
ICQ: 33292311    - email: 
mbel...@cs.unibo.it
IRC: RedGlow     - site(s): 
http://mbellett.web.cs.unibo.it/
Jabber: RedGlow  - Linux registered user 299762 @ machine 213003

 memoria.
In parole povere che č sto "lazy"?
E comunque i file che non vengono chiusi correttamente possono far salire la 
memoria?


 memoria?
Mi era parso di capire che tu comunque i file li chiudessi sempre, alla 
fine. Anyway; un po' di memoria e' associata a ogni file, per mantenere 
strutture dati in memoria contenenti i dati sul file, la posizione in 
cui ci si trova, un po' di cache degli ultimi dati letti, etc... - mi 
pare strano riuscire ad arrivare a consumare cosi' tanta memoria con 
file aperti, pero'! :P


 fine.
E in effetti lo faccio ma non controllo se effettivamente avviene quindi il 
mio sospetto era che io faccio close, questa fallisce, io non me ne accorgo 
e il riferimento al file resta appeso


 e il riferimento al file resta appeso
Credo che l'unica semantica sensata per una close sia quella o di non 
fallire, o di assicurare comunque che la sua memoria sia liberata anche 
in caso di fallimento, a meno che non preveda meccanismi di recupero. 
Non so in che framework ti muovi, quindi non so come funzioni.
Anyway: col tempo di queste botte e risposte, facevi prima a provare a 
mettere a posto il codice: non controllare i risultati di alcune 
operazioni e' sempre e comunque una brutta idea :)


 operazioni e' sempre e comunque una brutta idea :)
Il fatto è che in debug sembra tutto funzionare, i problemi ci sono solo 
dopo ore di uso intensivo
Il programma gestisce una piattaforma telefonica e non è facile fermare 
tutto per cambiare il programma in funzione
Comunque per togliersi ogni dubbio penso sia l'unica soluzione


 Comunque per togliersi ogni dubbio penso sia l'unica soluzione
Non avete un ambiente di testing? O_O


 potrebbe risultare corotto
Solo in un ambiente in qualche modo multithreading o multiprocess. Nel
primo caso ci sono tutta una serie di modi per evitare problemi (roba
che esula da C++ standard, che non conosce threads) e stesso discorso
per il multiprocess (fork e compagnia bella). Anche quelli sono fuori
standard.
Per quanto ne so io... close non dovrebbe poter fallire (nello standard,
intendo). Anche perche` c'e` scritto che viene chiamata dal distruttore
degli stream (supposto che stia usando gli streams), pertanto non
dovrebbe fare uscire eccezioni dalla chiamata della stessa.
Ed e` definita ritornare void.
Quindi *non puo`* comunicare errori. Dal che deduco che e` implementata
in modo che non ne generi.
-- 
RiK0
Non credo negli schemi non vincenti.

 intendo).
La close ceh usiamo è una fileclose che secondo la guida si comporta come la
fileclose di visualc e ritorna un intero che dice se è andata bene oppure
cosa è andato storto
Comunque stiamo andando un po' fuori tema
Vi ringrazio comunque del tempo dedicato
Se capisco cos'era vi faccio sapere


 Comunque per togliersi ogni dubbio penso sia l'unica soluzione
Ti ricordo che con GDB puoi fare il debugging di un processo in esecuzione,
anche se non so se puoi utilizzare GDB con Winzozz, ma immagino che anche
altri debuggers possano fare lo stesso. Quindi puoi far girare il programma
per tutto il tempo che vuoi e quindi iniziare una sessione di debugging
quando vedi che la memoria utilizzata supera una certa soglia.
Detto questo, escluderei a priori che delle close() non eseguite possano
essere responsabili di un uso di 200 MB di memoria aggiuntiva e non
prevista. Almeno non direttamente. Ritengo che quanto ti è già stato detto
su un probabile meccanismo "lazy" del S.O. sul recupero della memoria sia
più che probabile, e se così fosse non c'è da preoccuparsi. Vorrebbe solo
dire che hai memoria fisica a sufficenza e che non è richiesta da altre
applicazioni, tanto che il SO te la dealloca con tutta calma fino a
ritornare ai primi 50 MB di 'normale' utilizzo.
Buon divertimento,
fabiomdf
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Problema scovato
Tanto per cominciare da TaskManager di winzozz si legge il WorkingSet e non 
la memoria totale allocata dal processo
Questo giustifica il fatto che muovendo la finestra la memoria allocata 
scendeva di 200MB
In realtà 200MB di memoria vengono spostate sul pagefile ma rimane comunque 
allocata lì
La riprova è che:
1) la memoria virtuale era arrivata a più di 3GB
2) chiuso il programma è tornata a circa 1GB (su quella macchina ci gira un 
botto di roba)
Mi vergogno quasi a dirlo ma l'handle delle open lo castavo direttamente a 
unsigned ma quando la open falliva il -1 che restituiva portato a unsigned 
chissà dove puntava
Non me ne sono fregato più di tanto perché poi la play falliva, chiudevo il 
file e tutto come prima solo che in debug poteva succedere al più un paio di 
volte e non mi sono mai accorto di nulla
Mo non so se era l'handle unsigned(-1) che non si poteva chiudere o la play 
che voleva suonare un area di memoria che cissà dove puntava
Comunque interpretando correttamente i -1 delle open (scartando cioè i file 
che non si aprivano) tutto è tornato come prima
Vi ringrazio ancora del tempo dedicato e spero che la cosa possa essere di 
aiuto per qualcuno
