Memory leakage / memory problems

Richard Miller wow at together.net
Thu Sep 14 12:21:17 EDT 2006


No externals. I'm thinking that the principal problem may be coming  
from substacks continually opening and closing without their  
destroystack property set to true.  There are 55 substacks in the  
main stack, including some fairly large ones. None of them were set  
to purge memory on closing. That's been changed now and we'll test  
performance to see if the instability is eliminated.

Thanks, again, for all the suggestions.
Richard


On Sep 14, 2006, at 12:12 PM, Peter T. Evensen wrote:

> Look at your app in the task manager and look at the Process Tab  
> and Memory usage.
>
> If that keeps going up and up as you use the program, you have a  
> leak some place.  It may fluctuate, as you go different stacks and  
> cards.  If you have a main menu screen, however, it should return  
> to a constant value every time you return there.   If you go into  
> your program and back to the main screen and the number goes up  
> each time you do that, you definitely have a memory leak someplace.
>
> Another potential source of memory leaks is externals.  Do you use  
> any externals?
>
> At 05:33 AM 9/14/2006, you wrote:
>> Well, I'm not that knowledgeable about Windows either... Looking at
>> the Task Manager and the Performance area, which numbers are the
>> critical ones to monitor? Is it the "available" memory, and if so,
>> when does that number get so low that it becomes a problem? Do I
>> watch CPU usage?... or is the "commit charge" info a critical  
>> variable?
>>
>> Thanks.
>> Richard
>>
>>
>> On Sep 14, 2006, at 6:23 AM, Ian Wood wrote:
>>
>>> It might not be *your* program that's having problems. :-(
>>>
>>> I'm not that knowledgeable when it comes to Windows, but leaving
>>> the Task Manager open so that you can see what resources different
>>> apps are using would probably be a good start. Then leave it all
>>> running and wait until there are problems. Don't you just love
>>> intermittent bugs?
>>>
>>> Ian
>>>
>>> P.S. A notorious example of memory leaks on OS X is Safari - if you
>>> leave your computer up for long periods of time Safari can easily
>>> hit more than a GB of RAM after being open for a few days, even
>>> after you close most of the tabs and windows...
>>>
>>> On 14 Sep 2006, at 10:39, Richard Miller wrote:
>>>
>>>> Ian,
>>>>
>>>> This sounds like a possible culprit for the problem in our
>>>> application. Is there a way to find out what is causing this or to
>>>> verify it is occurring? Any code that can be written in? Any
>>>> specific places in the code to look for it?
>>>>
>>>> Again, what we are experiencing is the program bogging down or
>>>> simply freezing up at various points throughout a day, but never
>>>> at the same place. This is in runtime mode only.... not in the
>>>> development environment. No programming bugs show up there.
>>>>
>>>> Thanks.
>>>> Richard
>>>>
>>>>
>>>>
>>>> On Sep 14, 2006, at 5:27 AM, Ian Wood wrote:
>>>>
>>>>> Memory leaks are where a program grabs memory when needed, but
>>>>> doesn't release all of it afterwards. If the machine is up for a
>>>>> long time, even a minor memory leak can tie up all available RAM,
>>>>> bogging down the whole machine.
>>>>>
>>>>> Ian
>>>>>
>>>>> On 14 Sep 2006, at 10:23, Richard Miller wrote:
>>>>>
>>>>>> Peter,
>>>>>>
>>>>>> Can you explain what you mean by a memory leak and how that
>>>>>> effects stability?
>>>>>>
>>>>>> Thanks.
>>>>>> Richard
>>>>>
>>>>> _______________________________________________
>>>>> use-revolution mailing list
>>>>> use-revolution at lists.runrev.com
>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>>
>>>> _______________________________________________
>>>> use-revolution mailing list
>>>> use-revolution at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> Peter T. Evensen
> http://www.PetersRoadToHealth.com
> 314-629-5248 or 888-682-4588
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the Use-livecode mailing list