go stack/delete stack eats up memory in repeat loop

Mark Schonewille m.schonewille at economy-x-talk.com
Thu Jun 5 15:59:39 CDT 2008


Hi Bernd,

As long as the handler is running, Revolution can't do its memory  
management tasks. That might be why memory builds up. The workaround  
you found seems a good solution. I'd hesitate to call this a bug,  
although it might be useful to be able to clean up some memory along  
the way.

--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com
http://www.salery.biz

Benefit from our inexpensive hosting services. See http://economy-x-talk.com/server.html 
  for more info.

On 5 jun 2008, at 22:15, BNig wrote:

>
> Hi list,
>
> I would like some opinions on the following
>
> while evalutating a couple of thousand stacks of scientific data
> retrospectively I discovered that repeatedly opening a stack with go  
> stack
> aStack and doing some things and then deleting  stack aStack in one  
> handler
> eats up memory to the degree that Rev  uses all the available RAM  
> then some
> virtual memory and then crashes.
> This is on a MacBook Pro 2 GB RAM, MacOSX 10.5.2, 10.5.3,   
> Revolution Studio
> 2.9
>
>
> choose any stack of about 250 KB or greater and use activity monitor  
> to see
> the memory usage
> It uses about 1 GB physical RAM for 200 to 300 repeats
>
> on mouseUp
>    answer file "please choose a revolution stack to test for memory  
> usage"
>    if it is empty then exit mouseUp
>
>    put it into theFile
>    repeat with i = 1 to 700
>        go invisible stack theFile
>        delete stack theFile
>        -- with or without wait there is a memory buildup
>        wait 5 millisecs with messages
>        put i
>    end repeat
> end mouseUp
>
>
> The good thing is there is a workaround at least under 2.9 with the  
> send
> command (not working for Media 2.7.4, still eating memory)
>
> local theFile, theCounter
> on mouseUp pMouseBtnNo
>    answer file "please choose a revolution stack to test for memory  
> usage"
>    if it is empty then exit mouseUp
>
>    put it into theFile
>    put 0 into theCounter
>    send "goThatFile" to me in 10 millisecs
> end mouseUp
>
> on goThatFile
>    add 1 to theCounter
>    go invisible stack theFile
>    delete stack theFile
>    put theCounter
>    if theCounter < 1000 then send "goThatFile" to me in 5 millisecs
> end goThatFile
>
>
> So the question is whether one should consider it a bug or whether  
> it is
> what you expect since it is a "blocking" handler.
> It is probably not a situation that occurs very often, but my  
> feeling is
> that, well, Revolution should not crash when it runs out of memory.
>
> Anybody cares to comment on this?
>
> best regards
>
> Bernd Niggemann




More information about the use-livecode mailing list