[REBOL] Re: [view] crashing...
From: maximo:meteorstudios at: 15-Mar-2004 18:51
> -----Original Message-----
> From: Dide 
> Re: [view] crashing...
> > Can you provide any simple example of the memory leak so we
> can test it?
> Strange that different guys can think about the same problem
> in the same time !!
then we are more than one person trying to find the culprit :-)
> One ask about this kind of problem on the French Forum.
> In his case, memory of a face was not release as the face has
> a timer set on it (rate) and he doesn't hide the face before
> removing it from the parent/pane. So the timer was still
> running proving that the face was still here.
this is something quite hard to trap, I am sure he/you had a lot of fun tracking that
> I don't think it's your problem here.
I'm still trying to re-create the same memory leak in vid... maybe your example is just
> Anyway, I made this small program to test his problem (see at end).
> On my system, automatic GC occur when memory has grow to
> about 1.2MB (3.4 -> 4.6 -> 3.4MB).
will keep that number in mind... It seems plausible... as rebol always seems to be at
5.6 or 7.8 MB ram on my average view usage (when not using glayout)... which do have
1.2MB of difference
> If button 1) is pressed, memory grow to 7.4Mo (the face use
> big image to be "memory visible"). same behaviour : GC occur
> after 1.2MB more.
> But freeing the face with 2) or 3) button doesn't recover
> memory (still 7.4MB mini).
> Clicking 1) again make memory grow again, but this time
> memory is recoverable, down to 7.4MB that still be the
> minimun. You can try clicking fast, here it goes only up to ~15.5MB
> Button 2) and 3) can show the timer problem if you un-comment
> the 'rate line in the add-face func.
> This code (may be) demonstrate that 'layout or one of the
> func used in the layout process hold some reference on value,
> probably in local var, and so, some memory.
> Hope this help a little bit.
It shows that glayout is inheriting a problem from something which may well be multiplied
several times over since I call layout over and over.
my current guess is that there is something in the styles system which is leaking. if
each is added to a global styles list, then it is possible that some styles point to
a bogus block of data which is shared by more than one face and which constantly grows.
This would never get cleaned up because there is still one person pointing to block
which holds a value from the context...
this is a wild guess.. but there are so many obscure procedures in vid's layout dialect
that it sometimes get hard to make sure you've understood it all...
especially when you get to encounter lines like this (taken from layout):
if :var [set :var new new/var: to-word :var var: none]
next time I peruse the vid/view code, I'll try to see if there aren't any contexts being
used or datas left in local vars ... :-)