Newsgroup: it.comp.lang.visual-basic
Titolo: Out Of Memory

Ciao a tutti.
Ho un enorme problema di Out Of Memory nella mia applicazione scritta
in VB6 SP6.
Premetto che la dimensione del progetto ha raggiunto delle dimensioni
da non sottovalutare, in quanto è costituito da diversi nostri OCX,
una ventina di DLL e un eseguibile che contiene il "cuore" del
programma... per un totalino di 300.000 righe di codice circa (anche se
questo dato può essere irrilevante)
Il programma ha una form principale che contiene una decina di form
docktable aggangiate, e già questo penso rosichi diverse risorse.
L'apertura delle altre form è gestita in modo che posso aprirne
"infinite", ovvero immaginando un elenco di elementi possi aprire una
form per ogni elemento... un po' come se da Outlook aprissi tutte le
mail che mi ritrovo!
Aprendo per esempio un anagrafica (form che contiene la bellezza di un
150 controlli distribuiti su 7 tab il tutto con la bella interfaccina
XP con tanto di gradienti, ecc...) tutto funziona... il problema mi si
presenta quando, senza mai chiudere le form, apro 6 form di
anagrafica... questo mi fa andare in Out Of Memory il programma e penso
a causa dell'esaurimento delle risorse GDI in quanto a video vedo delle
cose pazzesche (bottoni che si spostano, colori che vanno
all'impazzata, ecc...) Lo stesso succede pure da VB e mi obbliga a
chiudere VB ed a riaprirlo... Ora quello che mi stupisce è il fatto
che quando succede questo, l'eseguibile mi sta occupando circa 40 Mb di
RAM sul mio PC che ha la bellezza di 1,5 Gb!!
Secondo voi, sono le risorse GDI che mi finiscono??? C'è qualche
soluzione per risolvere questo mio problema o devo spararmi nelle
palle??
Grazie a tutti.
Ciao
pEIIO

 palle??
La Ram nei pc moderni, fra quella fisica e quella paginata/paginabile, 
è quasi impossibile da esaurire.
Ben diverso il problema della GDI e della User, che, essendo 
indirizzate a 16bit per questioni di retrocompatibilità, sono 
limitatissime.
Ti suggerisco di monitorare il loro utilizzo mediante qualche tool (ne 
avevo visti di free, ma forse anche il performance monitor di Windows 
li visualizza).
Spippolando col tuo sw, ad un certo punto vedrai l'utilizzo di una di 
queste risorse alzarsi rapidamente ed esaurirsi. Con qualche prova, 
dovresti individuare il problema.
Il problema potrebbe però essere grave se si tratta di leak diffusi, 
sparsi qua e là.
Un caso abbastanza frequente è l'errore di avere controlli che durante 
l'esecuzione cambiano colore, ma il cui colore iniziale è stato 
cambiato a design-time, anzichè lasciarlo a default a design e 
cambiarlo nel Load. Sembra una cazzata, ma purtroppo ci sono parecchi 
leak su questo aspetto (diciamo che ce n'erano molti di più fino a SP3, 
poi sono migliorati tanto).
Ciao
Alberto
-- 
Autore di
"Petting for Dummies"

 
Ciao e grazie mille.
pEIO

pEIO® ha spiegato il 16/08/2005 :

Era un esempio di un problema noto, ma ce ne sono altri.
Magari il problema non è lì.
Direi che prima di tutto devi individuare *quando* l'applicativo 
diventa esoso di risorse.
E, come dicevo, con un tool di visualizzazione lo becchi in pochi 
minuti (se il problema appare così rapidamente come dicevi).


 Alberto
Grazie mille. Ciao.
pEIO

 utilizzare per verificare i punti dove si verifica il memory leack?
Anni fa ne usai uno di nome Mem_Manager o qualcosa di simile.
Poi (scusa la modestia) nei miei software di memory leak non ne ho più 
visti.
L'ultimo che ho beccato era dovuto a un servizio di monitoraggio Raid 
della Promise, e l'ho beccato col Performance Monitor di Windows (come 
ti avevo già scritto nel mio primo post...).


 
Ciao
pEIO

 quindicina di forms... :|
I memory leak (ma tutti i leak in generale) si evidenziano come 
integrale, o sommatoria, dell'esecuzione. Mi spiego meglio: se le 
risorse a tua disposizione sono 100, e il tuo leak ne mangia (in via 
definitiva) una al minuto, il problema si evidenzia dopo 100 minuti. Se 
ne mangia 50 al minuto, si evidenzia dopo 2 minuti.
Con questo ti invito a riflettere sul fatto che un applicativo 'grosso' 
impiegherà meno tempo di un applicativo piccolo, ma alla fine il leak 
arriverà comunque a saturare le risorse scarse.
Il fatto quindi che certi applicativi possano essere più piccoli dei 
tuoi (che, poi, riuscire a fare con un applicativo 'piccolo' quello che 
altri fanno con uno grande, può anche essere un pregio), non esime 
dalla problematica.
Soprattutto se consideri che i miei applicativi sono, per un buon 50%, 
cose che girano per anni senza interruzione (se posso, servizi NT, se 
non posso, eseguibili normalissimi).
Il problema dei leak, quando presi in mano VB6 per la prima volta, l'ho 
incontrato. Oggi, grazie ad una mia crescita ma soprattutto grazie ai 
vari SP di VisualStudio che hanno risolto quei problemi contro cui non 
c'era niente da fare, il problema è per me scomparso.
Resta per le cose di terze parti, come appunto quel servizio della 
Promise di cui ti dicevo, che ho beccato a fine 2004.


 
Grazie. Ciao
pEIO

 terze parti, quali appunto Janus GridEX e Codejocke...
Che non conosco.
Solo MS, qui (perchè, volenti o nolenti, è l'unico modo per avere 
supporto oggi e supporto domani).
