Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[view] crashing...

 [1/12] from: moliad::aei::ca at: 14-Mar-2004 14:31


hi all, I've been working hard on glayout, and its now entering clean-up stage. I had noticed a wild memory leak : EVERY new window would gobble up 6MB... even closed... only 300kb would come back. that when I noticed that I was re-creating a new style for every window... somehow, that is staying in ram even though the window is not visible and all of its reference (that I control) are set to none. I have changed method, Now, and am creating the style once and re-using it on all windows... Now with the shared style, opening a new window is about 50 times faster, but I loose 1 MB per window. Even when using vid direcly, I noticed a rather large 200-300 kb memory hole... glayout, had NEVER crashed once within the two weeks of operation, and now, since my style is shared, I can make rebol crash just by opening several windows EVERY time it gets started ... when it crashes is upon opening or closing a window. The actual number or windows I can open before a crash is completely variable , but I am guessing that its whenever a garbage collection occurs. Furthermore I still get a memory leak ON EACH window but... its already better since only 1MB is leaking ... not that its great... but better. if it where only a fact that a function block keeps a reference to the last window opened, I should be getting a leak only the first time IMO... maybe it is view or layout themselves which have a leak, and since I am calling vid several times, it eventually creates larger leakeage... I am using v1.2.10... has anyone had bad experiences like this one, or know of any specific issues with styles (using the stylize function) ? note that as part of glayout, VID is automatically relaunched several times within the same layout... any help appreciated. -MAx

 [2/12] from: cyphre:seznam:cz at: 14-Mar-2004 23:04


Hi Max, Can you provide any simple example of the memory leak so we can test it? Thanks,. Cyphre

 [3/12] from: atruter:labyrinth:au at: 15-Mar-2004 10:11


> Now with the shared style, opening a new window is about 50 times > faster, but I > loose 1 MB per window. Even when using vid direcly, I noticed a rather > large > 200-300 kb memory hole...
If the style exhibits the problem under VIEW/VID directly (and in isolation), trim tbe fat and send it to the list ... a number of folks having been looking for memory use / loss cause for a while now.
> has anyone had bad experiences like this one, or know of any specific > issues > with styles (using the stylize function) ?
Can't say I've seen this myself. Don't overlook the image cache (populated by 'load-image and emptied with /clear) when trying to determine what is gobling up all those bytes! ;) Regards, Ashley

 [4/12] from: moliad:aei:ca at: 14-Mar-2004 22:13


Hi Ashley, I'm not using images, cause I want this to be as skinny as possible. I have not yet found the source of the leak... BUT!!! I did find the source of the crash... yipee! I do not know if this is solved (or even fixable) in version 1.2.41 (I have not yet have time to test it, but I will)... Simply put, I was not using the /new refinement of view when opening a new window from a button... Which proves that even the seasoned coders get caught up in the simplest of bugs... It had been so long that I'd stumbled on this, that I had completely forgotten... for all the new commers out there. When you call view and there is already an opened window... do not forget to use the /new refinement. Otherwise you are calling more than one event handler, and eventually it creates an unstable situation, which inevitably fails and crashes. the memory leak might also be linked to this as the window was also pointed to by the event-handler... looking into it. Anyhow, its progressing quite well, even if I wish it where going faster. It should be released during the week. glayout is going to be more complete than I had originally planned, which is why it is taking more time. I think its a good tradeoff, and I'm eager to get you guys to use it. If I find the/a source of memory leakage, I'll report back here :-) HTH! -MAx

 [5/12] from: moliad:aei:ca at: 14-Mar-2004 22:18


Hi cyphre,
> Can you provide any simple example of the memory leak so we can test it?
Well, considering that the leak could be anywhere in 45k of code.. for now, I have to find where it occurs... but, like I said, since the call to layout, can be done tens or even hundreds of times, even for just one window, it is possible that vid's small leakage is simply being multiplied several times, into something more considerable. I will be looking into all of this in more details as I continue to clean up and finish glayout, as soon as I find something, I will report back... thanks for the help! -MAx

 [6/12] from: ptretter:charter at: 14-Mar-2004 21:34


I thought that RT had a new Garbage Collector for the new /view coming. Any confirmation? Paul

 [7/12] from: carl::cybercraft::co::nz at: 15-Mar-2004 6:27

Re: crashing...


On 15-Mar-04, Maxim Olivier-Adlhoch wrote:
> Hi Ashley, > I'm not using images, cause I want this to be as skinny as possible.
<<quoted lines omitted: 4>>
> Simply put, I was not using the /new refinement of view when opening > a new window from a button...
Normally that just replaces the current window, which is rather obvious to see. Were you managing to open a new window without the current one disapearing? -- Carl Read

 [8/12] from: maximo:meteorstudios at: 15-Mar-2004 10:29


> > Simply put, I was not using the /new refinement of view when opening > > a new window from a button... > > Normally that just replaces the current window, which is rather > obvious to see. Were you managing to open a new window without the > current one disapearing? >
yep! That is because it was being launched from within a ui, not from the main execution thread or from the command line. by what I understand, using the /new refinement simply tells view not to call do-events. concerning the memory leak. its strange, cause opening and closing the same window over and over will now almost shrink rebol's memory usage. BUT everytime I open a new window simultaneously, then each one gobbles up a 1MB chunk of which only 300 come back. resizing windows does seem to enlarge and shrink back memory useage pretty cleanly... so I'm not thinking that its the actual glayout engine which is greedy. If you open up to the maximum number of windows you've opened, then memory usage will stay almost flat, coming back down, if you don't go above the number of windows you've opened so far. I'm trying to see if standard Vid useage does this, and I think so, cause I've always noticed some strange memory leaks when using vid, even directly, with standard styles. Does anyone if using the function 'recycle will actually force a garbage collection? or will it only do so it if it deems itself appropriate (enough garbage)? Does anyone know if the (temporary) /torture refinement of recycle does a garbage collection everytime memory is trashed? or else, what it does? TIA! -MAx

 [9/12] from: didec:tiscali at: 16-Mar-2004 0:23

Re: [view] crashing...


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 !! 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. I don't think it's your problem here. 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). 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. DideC --------CODE BELOW -------- View/new lay: layout [ b: box across text "Allocated memory (MB) :" info 100 rate 2 feel [ engage: func [f a e][f/text: to-string stats / 1000000 show f] ] below button 320 "1) add a big face with rate" [add-face] button 320 "2) Hide and remove big face with timer" [hide-face remove-face] button 320 "3) Just remove big face without hiding first" [remove-face] button 320 "4) recycle" [recycle] ] add-face: does [ b/pane: layout [ text "here" (make image! 1000x1000) ; rate 1 feel [ engage: func [f a e][print now/time] ] ] show lay ] hide-face: does [if object? b/pane [hide b/pane]] remove-face: does [ b/pane: none layout [text ""] ; try locking loaccal vars of layout on a smaller face show lay ] do-events

 [10/12] from: maximo:meteorstudios at: 15-Mar-2004 18:51


allo,
> -----Original Message----- > From: Dide []
<<quoted lines omitted: 3>>
> 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 one!
> 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 the thing...
> 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
<<quoted lines omitted: 10>>
> probably in local var, and so, some memory. > Hope this help a little bit.
yesss! 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 ... :-) merci! -MAx

 [11/12] from: ammon:addept:ws at: 15-Mar-2004 18:07


I get an error... ** Script Error: stats has no value ** Where: wake-event ** Near: f/text: to-string stats / 1000000 HTH Ammon ;~> ----- Original Message ----- From: "Dide" <[didec--tiscali--fr]> To: <[rebol-list--rebol--com]> Sent: Monday, March 15, 2004 4:23 PM Subject: [REBOL] Re: [view] crashing...
> 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 !!
> 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.
> I don't think it's your problem here. > > 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).
> 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.

 [12/12] from: didec:tiscali at: 17-Mar-2004 0:13


Re: [view] crashing... Hi Anton,
> I get an error... > > ** Script Error: stats has no value > ** Where: wake-event > ** Near: f/text: to-string stats / 1000000 > > HTH > Ammon ;~> >
Sorry, I forget to mention that you need View 1.2.10+ to run the code since stats appear in this version. DideC

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted