Zugg Software :: View topic - [3.08] Continue to see random lock-ups

Posted: Tue Jun 02, 2009 7:45 pm

I continue to see random lock-ups of CMud, although it doesn't happen but perhaps once a week.

I'm not sure what other information I can give. Nothing is happening when the lockup occurs that doesn't occur hundreds of thousands of times without locking up. I'd gather more information from Cmud, except that nothing can be done with it once it locks up. I'd also be willing to test out new configurations or play around with what scripts I have running, except since lock-ups only occur maybe once a week it would take me 50 years to hone in on anything.

I'm curious as to whether there might be a way for Zugg to add in some code to Cmud to detect lockup conditions and then to terminate the program with a crash dump sufficiently verbose to help diagnose what the issue was.

Posted: Wed Jun 03, 2009 4:43 pm

Usually a lockup is a thread lock issue and there is no way to trap that at all. If you are using any threads in CMUD, make sure you protect your data access using #SECTIONS. Also try to notice anything in common when it happens, like if you have the Settings Editor window open or not, etc.

But usually this kind of problem is tied to some obscure thread issue in one of your scripts. As you say, it's going to be very difficult and time-consuming to track it down. You might keep the Script Debugger window open to see if it locks up on the same script execution each time. Just make sure to turn on the "Show Script Execution" message (or whatever it's called) at the bottom of the Messages menu. For something like this, you can probably safely turn off the Raw Input/Output messages to keep the debugger window from slowing down so much.

Posted: Wed Jun 03, 2009 5:30 pm

I don't use threads.

Posted: Wed Jun 03, 2009 11:05 pm

Well, you actually do, but you just might not know about it. Every trigger uses a thread. And the command line uses it's own thread. Triggers are handled to try and ensure that only one is running at any time. But if any script uses the #WAIT command, then it runs in parallel with other trigger threads. For the command line, there is an option in the Preferences to turn off using a new thread for the command line. You might try this option for a week or so and see if that makes any difference.

For example, if you type a command into the command line that takes a while to run and then enter another command and press Enter before the first command is finished, then you are technically running two threads at the same time. And with the command line thread option enabled, your command line is running in parallel with any triggers that are firing.

And finally, the Settings Editor uses another thread to access your script objects, which is why I mention paying close attention to whether the problem only happens when the settings editor is open.

Once last thread is created every 30 minutes or so to save your setting changes to your *.PKG file in the background. You can force this to happen more often by putting a #SAVE command in an alarm. If this increases the frequency of lock-ups, then it might indicate a problem with a script interfering with the background updater. This would be very unusual, but it's possible in theory.

Posted: Thu Jun 04, 2009 12:39 am

Summary:

- I'll try turning off the new thread for the command line
- The settings editor is always closed.
- The background saving is interesting. I'll try the #save to increase the frequency.

Posted: Fri Jun 12, 2009 8:43 pm

With regards to the third item on the list above (background saving). What happens if it is unable to save, would it cause Cmud to hang? With Virus 'protection' jumping in and scanning things it seems like something if things are busy it might take it a while to actually write to disk. Does it stall the program during this time? Sometimes I see Cmud freeze for 10 seconds and then everything starts up again like nothing happened.