Zugg Software :: View topic

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I've been having a problem with CMUD completely locking up, after being online for anywhere from a few seconds to a few hours. The computer is fine - I can still work with other programs and force CMUD down with the Task Manager, but CMUD itself becomes completely nonreactive, unable to scroll windows or execute menu options. Sometimes instead of locking up, I get very strange messages such as "ERROR: Operation divide by zero requires two arguments" (as far as I know, you can never divide by zero, regardless of how many arguments you use). When I get these messages, the scripts continue running for several minutes before the program locks up. I rarely get the error dump from CMUD itself.

While composing this post, I got for the first time an error from CMUD, several times, saying "Thread creation error: Not enough storage is available to process this command." and I discovered that CMUD is using 1.7 GB of computer memory.

I have already backed up to XML, uninstalled and reinstalled CMUD. I have disabled classes when they're not being used, and the only classes that have been active every time I've locked up are my core scripts that regulate all my other complex scripts.

This for for Dragonrealms, and all of this code is original so if explanation is needed, I can definitely provide. If anything looks awry and/or simplifiable, I would greatly appreciate it. Here is the code:

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

The memory thing must have been a fluke. I got the error twice, then left my Process Explorer open to watch the memory usage while doing things like opening the map, and it didn't happen again. It's been stable for 10 minutes of full-on scripting now using only 52 Mb of memory.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I'm continuing to have lockup issues with CMUD, and am no closer to finding the cause. I need suggestions to track down this annoying bug. What tools are there other than the script debugger (which has been useless in this issue) to help identify what's causing CMUD to lock up?

Posted: Thu Aug 25, 2011 7:26 pm

One thing you can try, is to read the following two posts and make the changes they refer to in your script above.

http://forums.zuggsoft.com/forums/viewtopic.php?t=36226
http://forums.zuggsoft.com/forums/viewtopic.php?p=113326

More specifically what I am talking about is the way you are referencing and assigning variables incorrectly.

edit:
I had a bit of a headache earlier making staring at the xml a bit difficult. After a hand full of aspirin and and a nap, I looked the code over again. Since it looks like core is a class and not the main window/module those posts won't help much. Sorry about that.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I appreciate the input anyhow. I read those posts and learned something... my choice early on was to avoid different packages or windows. I only format secondary windows using %ansi so that things don't get confused like I read about in those other posts. I did change the variable assignments to be explicit from the module's root to avoid other confusions I noticed happening.

I'm completely baffled with my lockups. Yesterday it locked up 5 times in a row, within a few minutes of each other while doing entirely different things (twice outside of roundtime, so these core scripts were unlikely to have caused the lockup), but today I've logged about 6 hours without a single critical error.

One error I AM getting that I can't explain and may be related is this: every once in a while, the Status Window's display is shown in the primary game window and sent to the MUD. Anyone familiar with this error?

Wizard Joined: 22 Mar 2007 Posts: 2320

It sounds like you have either a runaway loop or are accidentally creating a ton of threads, which are eating up all the CPU and freezing your Cmud. That's a very complicated script, and I can't tell at first glance whether there are any problems in it. The only thing that leaps out at me is that you use #EXEC when you don't have to. #EXEC is slow and should be avoided whenever possible. Code in #EXEC is not compiled, and has to be compiled during runtime. I think you can use #CALL in that particular instance. However, I don't think that is your problem. It looks like there may be some triggers that fire frequently. But this script is too complicated for a quick analysis.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I realize it's complex, and that's why I'm asking the experts here. =P

The only use of #EXEC is intentional because some scripts pass a variable into the queue that needs to be evaluated at runtime. It's never more complicated than a variable substitution or an %if.

I have looked very carefully at all of my loops and waits, and I can't find any that could go infinite.

Any comment on the information that's supposed to be in the status window being sent to the MUD? What could possibly cause that to happen?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

My guess is that you have too much of a process load hitting CMud all at once. I see the same thing with the reception of the raw GMCP strings that CMud parses into the various %gmcp values, but it only happens when I'm on a speedwalk and Aard's sending me hundreds of lines in a very short span.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I get locked up even when doing very mundane things that cause very little MUD output; it can go hours with no lockup when in combat and dozens of triggers are firing all at once. I'm going to study #THREAD and see if there's a solution in there... any strategies for using it would be appreciated.

Perhaps this is another clue: sometimes I get a bunch of errors referring to commands that I don't use. For example

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

Here's another oddity that keeps cropping up... some of the scripts stop working. It seems to be the trigger rtDetect (code above) that's not activating. If I manually "Execute script" from the Package Editor, it will fire. Once. But the button gauges stop updating automatically. If I disable the "Core" class, they all vanish, as expected, but when I re-enable the class, they don't reappear. Buttons in other classes will disappear and reappear when their respective classes are turned on or off, and all other triggers fire, but my Core class just stops working. The only way I can get it to fix is to restart CMUD. Note that if I save the package while it's in this non-functional state then restart CMUD, it works normal.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

This issue is not resolved, but I may be closer to the solution. I've adjusted the triggers in the core scripts to use "#SECTION". This has reduced the frequency of random lockups, but hasn't stopped them - it still occasionally locks up within 3 minutes 4 or 5 times in a row, then runs for an hour or more without any errors. Also, I now occasionally "see" what the lockup is - I get two error messages that alternate and give infinite scroll. Because it's scrolling too fast, I can't read the messages, but they both start with "ERROR: Operation", and I'm pretty sure one of them says "CONCAT requires two arguments", and the other says some other operation requires two arguments, which is longer than "CONCAT" and is not all caps, but beyond that I can't tell what it is.

Big question: When I get these "ERROR: Operation ______ requires two arguments" errors, is there any way to figure out what code is producing the error? Maybe a debug setting or logfile that I haven't discovered?

The script debugger doesn't work like I expect. I've read the documentation and figured out a few things, but there's still a lot of mystery behind it - is there documentation somewhere other than internally? Biggest issue I have is that when I deselect a single class from the class tree (as I attempt to narrow down the error), the debugger stops completely. So either it shows all debugging messages or none. Another big issue is if the program locks up and the debugger window isn't already in the front, I can't see what's on it! When I bring it to the front while CMUD is locked up, it doesn't refresh the debugger window at all.

Wanderer Joined: 02 Jul 2002 Posts: 74 Location: USA

Just a suggestion, but if you know concat is giving you issues, maybe set some debugging echoes that tell you whats going on before and after your concats? Looks like you've only got seven of them, so it shouldn't take much. You'd at least get a better idea of where things are breaking down.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

...and a very good suggestion it is. I've rewritten all active scripts to avoid the %concat function and still get that error. Said rewrites were much less efficient and had other bugs so I returned to this code.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I've been playing with debugger and learning how to work it. I still don't get why I deselecting a single setting in the tree makes the debugger stop running, but it's not so utterly useless to me anymore. From what I though was an unrelated bug, I tracked down what I think may be the cause:

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

With the change above (using #SECTION and adding the #IF statement in trigger queueTick), the program has been much much more stable. But it still locks up, so this isn't the only problem. I'm still seeking a solution.