Zugg Software :: View topic

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

I am having a problem with CMUD locking up at random intervals again. Last time I had this particular issue, it took a month to track it down, and it turned out that an expression variable was firing when it shouldn't have been and the fix was to use an #IF command at the beginning of said trigger to verify that the expressions were true. To be very specific, here is the "fixed" code:

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

[sarcasm]I just love when I get this:

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

Try to note what line you receive when this happens and then look at all the scripts related to any line of input/output 2-3 lines before and after that.

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

I'm continuing to experience this same problem. It's intermittant, which makes it very difficult to track down, and the lockup tends to be where CMUD just stops responding. The error I quoted earlier is baffling, and I'd still like to know what it means. Specifically, what is NEQ? Additionally, I've been getting the following errors scrolling down the page locking up the program:

Posted: Thu Oct 20, 2011 6:30 pm

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

Thanks for the references. I'm completely ignorant of Delphi - I only know that it's a machine language that other languages are built on, but that's the limit of it. Is there any way to get CMUD to report what's going on with CMUD whenever these errors occur? I certainly do consider what scripts could be firing when these errors occur, but there are just too many possibilities to narrow the field down. And since I can't replicate the error, I don't have the option of turning off this class or that just to track the bug - if I disable the any of classes that I suspect are the cause, then none of my other scripts will work and I can't just keep playing as normal until I get an error or not. Even if I could get by with these suspect classes disabled, since the errors are so sporadic I won't know if it's solved or not. Sometimes I'll go days (ready many, many hours of running the scripts) without a lockup.

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

I'm just having all sorts of issues this morning. Here's one that I've seen three times (does not crash the program):

Wizard Joined: 22 Mar 2007 Posts: 2320

I'm not sure you can trust %len on a stringlist. Since the structure of stringlists has changed from Zmud, it may be that %len does not work consistently on them. But I don't know whether that's the cause of your discrepancy. You need to be somewhat cautious when you treat a stringlist as a pure string; they aren't really the same.

As for your original problem, did you verify that @loop and @queue were actually pointing to @/core/queue/loop and @/core/queue/queue? If you had a spurious variable laying around, that could explain why the trigger fired when you thought it shouldn't.

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

That would make sense, and I've already adjusted all of the scripts that manipulate these variables to point specifically at the /core/queue/ class. When things start to go wonky, one of the first things I look for is extra variables by the same name, and I haven't had an extra @queue or @loop since I made those changes a couple months ago.

As for not trusting %len... The only trigger that uses %len is the one that catches the anomaly. The expression trigger that's supposed to fire has a value of "@rt and (@loop or @queue)", and fires even when both @loop and @queue are empty. The %len is actually more reliable than %numitems or just having the variable in the expression trigger's value. In fact now that I'm thinking about this, I'm going to adjust the trigger to look for the length of the variable rather than its value.

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

Heh. Made the adjustment, and CMUD immediately locked up. So using %len in the trigger isn't the solution.

Wizard Joined: 22 Mar 2007 Posts: 2320

You are still using @loop and @queue in your trigger pattern instead of @/core/queue/loop and @/core/queue/queue, but if you've checked for the existence of duplicate variables then that isn't your problem.

I do see a problem with your trigger logic. If @loop and @queue both equalled {0}, your trigger pattern would evaluate to FALSE even though both variables had an item. However, it looks like the values being added to the variables should never be 0, that should not be a problem. In any case, your current problem is the trigger firing when not expected, instead of not firing when expected.

Ah! Now I think I see a problem that could be causing your symptoms. You are using an expression trigger on certain variables, and then changing those variables. The trigger will be tested every time one of the variables is changed, and fire if the pattern tests TRUE. The freshly fired trigger will wait for the current execution to finish before starting execution. This should work, but as your code is currently written, you can sometimes change one of the variables twice. You use the #SECTION command, which I think may cause this code to execute in a separate thread from the command line. I wonder whether this would cause the trigger to be tested twice, as you change the variable twice. If it does, you could end up with a backlog of fired triggers waiting for the , some of which will try to execute after the loops are emptied. If this is what is happening, the trigger fired while the @queue and @loop had items, but sometimes don't execute until they don't.

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

Thank you very much for examining my code. I'm very frustrated with these frequent

I put the #SECTION command in there to prevent this. I thought by assigning it as a section, it would execute the entire block before doing anything else, preventing unexpected tampering with the variables involved while executing. I didn't realize that it would create any sort of backlog stack.

Notice that the first thing the script actually does is turn itself off (Line 3, after #SECTION and #IF). I've adjusted the script so it turns itself off in the very first line, which required an extra line at the end. I've also adjusted how it handles the looping string. Here's the tweaked setting:

Wizard Joined: 22 Mar 2007 Posts: 2320

What the #SECTION command does is prevent any other #SECTION with the same name from executing at the same time. This is to prevent separate threads from interfering by changing the same variables at the same time; those other threads have to wait to execute that section until the running section finishes. But it does not prevent any other thread which does not have a section with the same name from running. The test for whether a variable used in an expression trigger has changed occurs in the main thread, and does not happen in a named section. If this code were not in a #SECTION, it would run in the main thread, and the test would perforce occur after the entire trigger was finished--you would not have this particular problem (but might have other problems if you have other threads trying to change these variables). The main thread continously runs through a loop of activities, such as parsing input from the mud, checking and executing commands from the command line, checking alarms, and checking for changed variables used in expression triggers. What I thought was happening is that your script (running in a separate thread) changes one of the variables twice, and there is a small probability that the main thread happens to check the variables during the small interval between the two changes. When it does, it tests the expression and fires the trigger and starts executing, but then has to wait until the already running #SECTION finishes. Then the variable changes the second time and the trigger is fired again sometime later.

However, you just pointed out that you use #T- to turn off the trigger, before the variables are changed. I think that should prevent this scenario from happening. So, I'm at a loss again. It still sounds like some kind of obscure thread interference, but I can't see what it could be.

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

So what you're saying is that the inclusion of the #SECTION does absolutely nothing if there is not another setting with #SECTION using the same name? I thought it protected any of the settings that are referenced in the #SECTION.

Even after the changes outlined above, I'm still getting the occasional lockup. The only other script that is (almost?) always running when I get a lockup is my timer script. Perhaps this is the culprit? (this is a lot less than it looks at first glance - each setting is just a few lines)

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

Here's an interesting one:

Wizard Joined: 22 Mar 2007 Posts: 2320

Aha...you have a potential thread interference here. You have that other code where you change the value of @queue surrounded by #SECTION, but you don't have this code in a #SECTION. That means these two pieces of code could be running at the same time, and the value of @queue could change between the time that you test the value of @queue and the time you go to use it within the same code.

As I indicated before, #SECTION does not automatically protect the variables within that piece of code. It merely provides a mechanism for such protection. If you have different pieces of code which might be running at the same time in separate threads changing the value of the same global variables, you need to put all those pieces of code into a #SECTION with the same name. Try not to put more code within #SECTION than is necessary, to avoid blocking other threads more than you need to.

Before doing this, tell me: do any sections of code manipulating @queue actually need to be in a separate thread? If they don't, then the easiest solution is to not use any thread commands in those scripts. Right now, your #SECTION command is putting that one script into a separate thread. If all of your other code manipulating @queue is running in the main thread, just take out the #SECTION command completely.

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

I'm not quite sure whether or not I need separate threads but I don't think so. I'm not formally trained in programming, and I'm not entirely clear on how threads work but I'm slowly piecing them together. Maybe I'm sewing them together. With thread. At any rate, I've removed from my package every instance of #SECTION until I learn to use them responsibly. They only existed in my core scripts, which are the ones in question, with the purpose of preventing this error.

I just did a search for "queue=" and there are only 6 settings that directly assign a value to @queue (not including a couple #ADD/DELITEM commands). Three are pattern triggers which are definitely not the problem. The other three settings are aliases that I use all the time and are called by many many other scripts. The one used most frequently is the alias "q", which I've brought under the proverbial microscope.

After the error yesterday (described in my post above), I changed the alias from this:

Wizard Joined: 22 Mar 2007 Posts: 2320

If you aren't using #THREAD, #WAIT, #WAITFOR, #WAITSIGNAL, or #WAITTHREAD, then you aren't using threads and don't need #SECTION. All your #SECTION would be doing in that case is creating a thread you don't need, and exposing you to potential thread problems. If you don't need to use those commands, then it is always safest to avoid threads entirely. Threads can cause lots of subtle problems that are hard to debug.

I strongly suspect that most of your problems, including the apparent firing of triggers and #IFs when you think the variables are empty, were caused by creating a separate thread for that trigger and the consequent thread collisions.

It sounds like you have it working, which is great! If it becomes a problem again, let us know.

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

The problem is persisting. I went for quite a while with no indication that there was any problem with the scripts, but now I'm getting locked up again... I'm open to new suggestions.

Wizard Joined: 22 Mar 2007 Posts: 2320

The only new idea I have off the top of my head is that perhaps the lockup is in a different section of code. You were only assuming that the recent lockups were in this code because you had had a problem with it before.

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

I was not assuming that only because I had a problem with it before, though that's a primary reason. I've also narrowed down the problem by disabling non-essential classes, and the Core class is the only one that's been active every single time CMUD has locked up.

If I could understand what's up with the Script Debugger, I think it would go a long way to continue narrowing down, but no one seems to have any input on why the Script Debugger's class filter doesn't work. Oh, well. I'll keep trying little bits until it stops locking up.

Wizard Joined: 17 Jun 2006 Posts: 1201

There seems to be an issue with that XML. Anyone else able to import that class above? I get an error on line 51 stating invalid XML name.

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

I'm not entirely sure how the < got in there when I think I copied and pasted from the XML tab. The error you're getting is because in XML the < symbol means the beginning of a tag, but I mean it to be the logical qualifier of less than, which in XML code is replaced with <
Here's the adjustment, also including other changes I've made to the script:

Wizard Joined: 17 Jun 2006 Posts: 1201

Yeah I found it. Change that less than symbol to "& lt;" without the space. For some reason, the code tags aren't working when it comes to this.

Then it will import fine. Also put spaces in your code geesh. Makes it hard to read it without them. Razz