LiveCode Forums.

Hi: I am still having an intermitent issue with my Windows standalone screen freezing / locking up . It usually happens after running the app for many hours. The screen is locked and frozen, but the stack continues to function. The only way to unlock the screen is to resize the window. I am not using lockscreen in any script, and this happens with all of my LC Windows standalones that include timed event loops (ie: send dothisagain to me in .5 seconds). I have logged all pending messages to see if they are multiplying, and they are not. Do you think it's a memory issue? How can I periodically do a 'clean-up' of memory issues? Maybe that would solve it.

It's possible that it's a memory leark. They're very rare in LC, and I've seen only a handful since I started using this engine in '97, but once discovered the engine team has been very quick to fix them.

However, to rule out other possibilities it may be helpful to first double-check a couple things.

First, can you use the Program Manager (Control-Alt-Delete) to monitor memory size in the app? If you see it growing without ever shrinking that may indicate a leak.

But also, double-check that you have the most recent system updates, esp. those for your graphics card. I've seen many cases over the years where just bringing the graphics driver up to date resolved otherwise-mysterious issues.

excellent suggestions. I'll watch the memory usage, and run some updates for the graphics card.

Memory leaks. I think this might be the problem. I've been watching memory for a few different instances of my Windows standalones running with the Task Manager, and the instances of the app that have the pendingmessages turned off, do not show any memory growth, But, the instances of apps that cycle through "send something to me in 1 second" are growing - even though the messages aren't stacking up.

Is there a way that I can periodically dump or reset memory without having to restart the app?

Greg

Are you certain those pending messages aren't stacking up? Memory leaks happen, but they're fairly rare, esp. on Windows; given the number of people who rely on this engine on that platform they tend to get caught fairly early one. Not impossible, but rare.

If your script doesn't already do this, it can be helpful to include a check for a given message before issuing another "send", e.g.:
If you're already doing that we may need to look at other possible causes.

pretty sure. I use a handler in my stack script:

in stack script:

on cancelThisMsg
put the pendingmessages into tPendingMsgs
IF tMsg is in tPendingMsgs THEN
repeat FOR each line myx in tPendingMsgs
if tMsg is in myx THEN cancel item 1 of myx
end REPEAT
END IF
END cancelThisMsg

To start the loop:

global tMSG

on mouseUp
if the hilite of me is true then
checkfororders
else
put "checkfororders" into tMSG
cancelThisMsg
end if
put the pendingmessages into field "PD" on stack "switcher"
end mouseUp

Also - I watch pendingmessages, and it looks clean.

That looks pretty thorough.

A useful next step might be to see if you can come up with an isolated example of this, the simplest stack that evidences the memory loss.

It can sometimes be a bit of work to come up with a good example, but if you can and submit it with a bug report chances are it'll be addressed almost immediately.

Is checkForOrders the routine that's starting the timer? Does the timer routine itself check for pending messages before starting a new instance? The only thing I see here that clears out the pendingMessages is the mouseUp handler, which wouldn't account for a buildup of messages over time.

mwieder wrote:Is checkForOrders the routine that's starting the timer? Does the timer routine itself check for pending messages before starting a new instance? The only thing I see here that clears out the pendingMessages is the mouseUp handler, which wouldn't account for a buildup of messages over time.

This is the checkfororders handler:


on checkfororders
if the hilite of button "ListenOrders" on stack "Switcher" is true then
put "file:" & defaultfolder & "/LIVEdata/LIVEorders.txt" into LIVEOplace
put URL LIVEOplace into LIVEorders
if LIVEorders is not empty then
split LIVEorders by "%"
repeat for each key mykey in LIVEorders
put the date && the time & tab & LIVEorders[mykey] & return & return after currentorders
set the itemdelimiter to tab
wait 1 milliseconds with messages
end repeat
put currentorders & return & return before field "orderLog" on stack "Switcher"
put "" into URL LIVEOplace
FillOrders
end if
calculateit
send mouseup to button "cleanup" on stack "Switcher"
send mouseup to button "filter" on stack "account"
send mouseup to button "get em" on stack "Eplotter2"
if "checkfororders" is not among the lines of the pendingmessages then send checkfororders to me in .5 seconds
wait 1 milliseconds with messages
end if
end checkfororders

When the screen freezes, try typing command-period (or control-period on Windows.) If you're lucky you'll drop into some handler that's hung things so you can see what it is. It may not work because you've structured your script well and I don't see any major blocking loops, but if the timing is right you might hit on something. It's what I usually try when I'm desperate.

you know... i dont see how my problem can be related to the timer messages, or memory filling up. The problem is that the screen FREEZES after many hours of running. The solution is to simply resize the stack - even by 1 pixel. If the problem was related to memory leakage, then resizing the stack does not flush memory - the mem stays the same, yet the app will start functioning properly again. Also - when the screen freeze happens, the app continues to function - but nothing shown on the screen. I can click a button, and it's script will be activated, but I see nothing on the screen. It is similar to lockscreen being set to true (I'm not using lockscreen, and I have tried including "set lockscreen to false" in my timer message.

jacque wrote:When the screen freezes, try typing command-period (or control-period on Windows.) If you're lucky you'll drop into some handler that's hung things so you can see what it is. It may not work because you've structured your script well and I don't see any major blocking loops, but if the timing is right you might hit on something. It's what I usually try when I'm desperate.

The screen freezing problem happens when running the WIndows STANDALONE. control period will have no effect.

The problem with the screen freezing is with Windows. I was able to recreate it by creating a stack that had a very active screen - many small squares that changed colours with random numbers fluctuating in fields. I let this test stack run over night, and the screen was frozen in the morning. However, the stack was still functioning in the background - just nothing was changing on the screen.

I was able to solve the problem with a bit of a clunky work-around. I wrote a handler that resizes the stack by 1 pixel, then back to it's original size every hour. This resize happens so fast, you can't see it, but strangely enough, it resolves the screen freezing issue!

If you would like a copy of the test app WIndows standalone to run on your windows machine, let me know. I would like to know if anyone else is having this issue (perhaps it is related to my video card).

Greg

Dear Greg,

I'm sorry to hear of the issue you are experience.

If possible, could you report the issue to LiveCode quality control and we will happily investigate what could be causing it.

You will be able to do this at the following site-

http://quality.runrev.com

Kind Regards,

Neil Roger
--
RunRev Support Team ~ http://www.runrev.com
LiveCode – Realize fast, compile-free coding

--