Zugg Software :: View topic

Posted: Sat Feb 20, 2010 3:03 am

When executing long speedwalks, which recure sending the mud a long stack of commands, CMUD will go into an infinite loop as demonstrated by the fact that it locks the cpu at around 100%.
There hasn't been a way for me to find a way to get a dump yet. I am posting this in case others have had similar experiences.
The symptom is that the screen will freeze in the middle of the speedwalk and the cpu usage will climb toward 100% while cmud is hanging.
It doesn't happen every time but there is a good chance that it will happen at least 1 in 5 tries.

Posted: Mon Feb 22, 2010 5:54 pm

Without a dump showing exactly what commands and triggers are executing, there isn't much I can do.

I'd definitely take a look at any scripts that are running based upon your speedwalking. For example, triggers that fire on certain rooms, or specific room scripts. Especially if any scripts have any #WAITxxx commands in them.

I speedwalk around Aardwolf all the time, and some of the speedwalks are pretty long (30-40 steps), without a problem. You should also tells us what exactly you mean by "long" and share the exact speedwalk command you are sending. If you are using the mapper to speedwalk, you can always right-click a room and copy the speedwalk path to the clipboard to post it here.

Also, if using the mapper, you always need to tells us what speedwalk MODE you are using (fast,safe,slow).

Posted: Mon Feb 22, 2010 9:24 pm

First of all, my movement scripts have been around for a long time. It is only in 3.14 and 3.14a where I am experiencing this problem.
I don't use the mapper directly to generate the speedwalks. Instead, I use %pathfrom to generate the speedwalk which I then translate into a run command. This run command is then sent to the mud. So it is equivalent to my typing it on the command line.
I cannot get any normal dumps of the problem because cmud itself is not responding (it's locked doing something as indicated by the almost 100% usage of the cpu).
The reason I believe the problem is related to cmud's inability to process mud output is because it hangs displaying the progress of the speedwalk. I do reach the final destination of the walk, but I only find that out after I restart cmud. The fact that I finished the run means that cmud sent the entire command stack to the mud. It is the output from the mud related to the command stack that is causing cmud to hang.
If there is a way to monitor this, I'll be glad to do it. It happens often enough that it would not be any problem reproducing it.

Posted: Tue Feb 23, 2010 12:19 am

You might be able to capture it using the #DEBUGFILE command:

#DEBUGFILE test.raw test.txt

and then do the speedwalk. Then close CMUD and see if the file gets saved. It's possible the file buffer won't get flushed and won't get saved.

Nothing related to any of this changed in v3.14 or 3.14a. I've just tried some huge speedwalks and they work fine. But it sounds like you are manipulating the output. Try posting your exact RUN command so we can see it. You need to try and narrow this down to see if it is a problem related to a specific room or specific speedwalk path length.

As I said, my guess is that it's a script running based upon some room you are entering as part of your path that causes CMUD to hang.

The fact that you end up in the correct room is not surprising...you are sending the entire path to the MUD, and the MUD is processing it. But somewhere along the line when the MUD tries to display the room description, you must have some script that is triggering on the result and causing problems.

For example, if you have a trigger on your MUD prompt, then obviously that trigger is going to fire a *lot* during a long speedwalk. If there is a problem in that trigger, then that could cause this problem.

So also try your RUN command with your triggers disabled to see if that makes any difference. Or try it with the mapper window closed if you are using the mapper.

But you will have to do more playing around and testing of stuff like this to help pin it down because I can't get it to happen here.

Novice Joined: 26 Nov 2008 Posts: 33

I am also getting locked out of CMUD at mysterious, random times.

Moving into a room that I've moved into before with no problems.

Selectively clearing a list of all kills of a particular type: ($type,$buyer are params)
#local $temp
#forall @Kills
{
$temp = %pop(Kills)
#if ($temp==$type) {give $temp to $buyer} {Kills = %additem($temp,@Kills}
}

This will work 90% of the time, but CMUD will randomly lockup the other times. The only workaround I have tried is to not enter another command until receiving the first Imperian message not related to the process of giving all X to buyer Y.. This lockup has occurred before even sending another command to Imperian...just starting to type it in has caused the lockup after typing the first letter.

I've deleted the package and reimported it again and it still happens to me...always at a random time. I've no way of trying the #DEBUGFILE approach.

Posted: Mon Mar 01, 2010 5:51 pm

Did you verify that removing the above script from your room fixes the problem? Do you have any other script that might be changing the value of @Kills? If some other script is adding a value to @Kills, then your #forall loop might never end.

Your logic for this script is a bit flawed. If you have an item in your @Kills list that matches $type, then you add it back to the list. So it's possible that the loop will get hung because @Kills is never empty. You %pop a value, but then add it back again. So now @Kills has been modified so your #forall loop will loop again.

In programming, it is considered a *very bad idea* to ever modify the variable that you are looping on. Different languages handle this different ways. In the case of CMUD, it might be a timing or threading issue. But in any case, the result of changing the variable you are looping on is considered "undefined".

Novice Joined: 26 Nov 2008 Posts: 33

Thanks for responding, Zugg.

Actually, I give the item to the buyer if it matches and add it back if it doesn't. It works 90% of the time, but I take your point. I will add the nonmatchers to a temp var and then reset Kills to the temp var when the loop is done.

I have no room scripts running. Occasionally, when I enter a room, CMUD freezes up. I can enter that room later and it works fine.

I just had CMUD freeze up while in the middle of a fight. This has happened more than once also.

I started seeing these freeze-ups with 3.14/3.14a.

Thanks