Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
A more definitive statement about MEMORY LEAKS within VF
Message
De
01/11/1998 20:34:41
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Classes - VCX
Divers
Thread ID:
00153253
Message ID:
00153329
Vues:
21
David,

While I agree that the code is doing precisely what I tell it to do, and I even state that it is executing according to the documentation, this *DOES* consisiute a "memory leak", albeit within VFP only, for someone WHO DOES NOT KNOW THE "RULE" OF 'dangling references'.

And I'm sorry that I messed or forgot your prior about the accuracy of SYS(1016).

As I'm sure you will agree, the call for help with either 'slowdown after longish running' or 'my form won't go away even though I release it' or 'how can I run out of memory with my small application' or other similar ones come up frequently enough to show that lots and lots of people never saw the bit in the Developers/Programmers GUIDE about memory staying occupied if any 'dangling reference' remains.

Regards,

Jim N

>Jim,
>
>First, As I've already mentioned a couple of places in recent threads SYS(1016) isn't exactly a reliable measurement of memory use. In VFP5a it's better than it was in VFP3 but it's not perfect.
>
>Second, your test code does exactly what you told it to, you've tried to create 99 instances of a 500K form in memory. The external references of the Ynn memvars to the internal textbox object of the form prevent the form from being released. It's no wonder your system ran out of memory at the 87 iteration.
>
>Add this block of code after the loop:
>
>
FOR LL = 1 to 03 step 1
>   LC = ltrim( str( LL, 2, 0 ) )
>   y&LC. = .null.
>   debugout "After nulled Y&LC. " + sys(1016)
>endfor
>
>debugout "at end " + sys(1016)
>
>x = createobject( "cForm" )
>debugout "final x" + sys(1016)
>
>I switched from ? to debugout because it's much more functional.
>
>The sys(1016) memory allocation goes down as each Ynn is nulled out therby allowing the form object to finish it's destruction.
>
>The last creation of another cForm does not take the 500K each of the first 3 did. So that memory pool was reused by VFP, even if sys(1016) didn't go back down to the original base value.
>
>Bottom line is that this is a total non-issue, it's caused entirely by improper coding. Don't expect Microsoft to change VFP so that it corrects a programmer error like this one.
>
>
MUCH snipped
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform