Zugg Software :: View topic - 3.22 aliases&variables becoming no longer visible internally

Apprentice Joined: 15 Jun 2010 Posts: 121

For aliases:

I am sorry I don't have a foolproof way to reproduce this since, since it happens somewhat rarely, but it has happened to me 3-4 times to the point where I have had to restart cmud to fix the issue.... (this usually happens when the mapper is slowwalking by the way)

The main problem is every once in a while CMUD will think that an alias does not exist... ie a trigger tries to execute alias and instead of executing it it ends up sending the alias command name to the mud (its like cmud's internal structure of whether a command is an alias or not gets broken)

Some of the time the problem fixes itself and I don't see the same alias name being sent as plain text again, but then once in a while something very bad will happen where since the alias is seemingly not existing, a script that fires on the prompt will send the name of the alias to the text (instead of executing the alias) and then the mud will respond with a (what are you talking about message) and another prompt and the script fires yet again and this ends up in a loop where I have to kill the internet connection to wait for it to stop spamming, close cmud and restart it to fix it.

After this loop ends, I noticed in the editor the aliases are not highlighted blue.. But I can create new aliases and execute them from the command line fine. Triggers and variables all seem to be working fine at this time, only all existing aliases are broken completely (in all modules and the main package)...

I tried disabling/reenabling aliases / and modules in the editor and tried executing them from the command line but this isn't making a difference (because of this it doesn't seem to have to do with a disabled flag as far as I can tell...)

Similarly for variables:

This happens far more often with variables, to the point where I have succumbed to putting most of the variables in my root folder

Every once in a while I will see a variable with the same name that exists in a different class in the same package being created in the root of the package folder.. The classes these variables are in are never disabled in any script, nor are any parent classes disabled in any script.

In one case I have a class folder called just "vars" in root, with a bunch of random variables, and those often end up with copies in the root folder of the package. This causes serious problems with every script that accessing these variables since there are two with the same name (one ends up getting set and the other one ends up getting read)

Zugg: I have left the process open (where aliases are completely broken), so if you can think of anything I can try when it is broken like this to give you more information, let me know.

Posted: Mon Jul 12, 2010 4:52 pm

In your Settings Editor, turn on the View/Show Default Packages menu and the View/Show Hidden option. Then turn OFF the View/Group by Class option. Now click the All tab. You should now see *all* settings no matter what package or class they are in. Check to see if your alias is listed there.

If the Alias is not listed, then somewhere in your script you are using an #UNALIAS or #UNCLASS command to remove the alias or the class containing it.

The issue with variables sounds more like you have some scripts running in other packages or modules that are confused about where the variables should be created. You will need to post more specific details about your exact scripts for help with that.

If this is happening with the mapper and you are using any room scripts in your map, then that might also be the problem. But we would need to see your room scripts and get more information about where your variables are being created.

It's also possible your package file is corrupted from some previous version of CMUD. It might be time to use the File/Export All menu option to export your settings, then create a new package and import the XML saved by the Export command.

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

Apprentice Joined: 15 Jun 2010 Posts: 121

For the aliases:
I am not using #UNALIAS / #UNCLASS anywhere....

Also it is a matter of ALL aliases in all packages end up not working .. I did those steps, and all the aliases that should be there are listed.

(It might be thread related... I thought it was some com stuff, so I disabled it, but it still happens, and it just happened last time when a thread was being processed...but it only happened once -- ie the prompt trigger sent an alias command name to the mud instead of executing it (alias is in same package))

For the variables:
I don't think this is the case with module/packages confusion.. because there end up being duplicate variables created in root that is in a different class but both are in the same package (that is the problem)... This happens from many different types of triggers, but for instance, I have a telnet type trigger (ATCP) that is the only trigger that sets the health variable (which is in class "Vars") to my current health, but randomly a duplicate is created in the (root) of the same package, and the class "vars" is never disabled by any script/trigger..

Zugg It seems that these bugs are related, and that in certain circumstances CMUD for some reason just can't tell whether a particular object like a variable or alias is existing in the package (Like in certain circumstances the internal lookup fails, and there is no error checking to see if the lookup failed).

I will try reimporting my package in the next version to see if it still happens (in case it is a corrupt package...)

Posted: Mon Jul 12, 2010 10:06 pm

If CMUD cannot tell if a variable or alias exists and it's not a scoping or context issue with your script, then your package is corrupted.

However, note that there is currently a bug in 3.22 that causes settings to get disabled in some cases when imported and that might be related to this problem if this is just something new happening in 3.22. This topic: http://forums.zuggsoft.com/forums/viewtopic.php?t=35463

There is really no way for the internal lookup to fail if the alias and variable is shown in the settings editor. The Tree View in the settings editor is showing the contents of the internal database, and the lookup is just doing a simple database lookup on this table. So if it's in the tree view, then it's going to be returned by the database lookup. So if this is failing, then something is corrupted somewhere.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Actually, it used to fail for me sometimes.

IF I recall correctly I made a macro that printed to the screen my aliases would start working again if I hit that macro.
I'm certain that I wrote a bug report about it, though I haven't looked it up yet.

Edit: This was a LONG LONG time ago and I could just be recalling the bug that Zugg was fixing here.
http://forums.zuggsoft.com/forums/viewtopic.php?t=24205

Apprentice Joined: 15 Jun 2010 Posts: 121

I spent a few hours trying to work this out, and started out reimporting into a fresh package (which didn't help)

I disabled all my com stuff but I still get problems

I am guessing but it does seem like some internal problem involving simultaneous multiple threads, where either a script in the main thread loses its context somehow of what thread it is in, or is unable to access some shared resource(table/or something) to determine in a script whether the alias/variable exists in the package.... this thought is based on the below:

I have been able to replicate both of these problems somewhat more certainly (I have replicated it at least like 20 times or so, so I am sure it is a real bug, although rare, and not just a fluke:

I have a script that does some map query stuff and does stuff like compute paths -- most of this script executes in a separate thread and is the only threaded script right now --- , and while this script processing in a separate thread .... in the main thread multiple prompts are received, firing my prompt trigger multiple times, and in a random number of those times, the aliases and variables will no longer be visible to the to main package's scripts/triggers, resulting in the above problems for aliases and variables...

Wizard Joined: 22 Mar 2007 Posts: 2320

That does sound like a bug in your code. When using threads, you need to be _very_ careful that the threads do not tread on each other. Multiple threads trying to manipulate the same variables will cause problems like this. If you post the code, we may be able to help you make your code thread-safe.

Apprentice Joined: 15 Jun 2010 Posts: 121

I am pretty sure there is nothing really unthread safe that is causing such huge problems ... most of the script is all local variables and querying the map database heavily:

Here is the script fyi:

http://paste-it.net/public/t3606da/

(Note, @terrains is just a static table, so can map environment types to color names... so it shows you all rooms with a certain room color, sorted by distance from the current room)

Posted: Tue Jul 13, 2010 10:22 pm

Sorry, maybe I'm missing something but I don't see you creating any regular variables at all in the script that you linked. So what variables are getting created in the root of the module. Where do *those* variables get accessed and created. Seems that you haven't shared the entire script or something. Otherwise your thread code looks just fine since it only uses local variables.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Dbosst, are saying that if you don't use the script you posted then you never have the problem with aliases not working? Are you also saying that the broken state only starts when that script is running in a second thread, and no other way?

Apprentice Joined: 15 Jun 2010 Posts: 121

Sorry if I wasn't clear, my prompt trigger and some other triggers (like telnet atcp trigger) are what are creating the DUPLICATE variables, and failing to execute certain aliases in the MAIN thread

It ONLY WHEN THIS threaded script runs where the problem occurs in my CURRENT package, and this is the one clear case where I am able to replicate the problem somewhat fairly consistently

However, Vjilante, before I wrote this threaded script, I had seen this problem with other scripts that did database/com but I couldn't consistently or with certainty to point to them as the problem... so I gave up on all that since it was causing problems and I removed all my com/database stuff just to be safe, after that I didn't see it again, but I couldn't point to exactly which part of code was causiing the problem....

After I wrote that threaded script fts I noticed I was able to reproduce it somewhat consistently..

For testing... I execute the script fts, and the thread starts running in the background then I hit enter a few times (to send an empty line) at the command line to get the MUD to respond back with a few prompts.... at which point my prompt trigger fires as well as some other triggers like ATCP etc ... during one or more of these triggers fire, something fails in the main thread's scripts for the trigger and at this point either the aliases are no longer visible in the main thread (end up not parsing the alias in the script and sending the text to the mud) as well as variables thus duplicates get created in (root), ie my ATCP trigger ends up creating duplicate health variable in (root)...

Zugg, if it helps here is the entire export xml, but its pretty big at (.5meg) :

http://www.mediafire.com/?gjywmitmotzwwmw

((I should add again that sometimes after testing it several times in a row, in reproducing the problem, every once in a while the alias problem will stick consistently, catastrophically.. to where I can't execute any alias and have to end up restarting it .. (it just won't get parsed from the command line or any script) but all my triggers and variables seem to be working fine... all the aliases are enabled and visible in the editor, and the packages they are in are all enabled... when it gets stuck like this its noticable because in my main prompt trigger one of the first lines is a line calling alias "i_exec", this ends up sending the text "i_exec" to the mud, instead of executing the alias, and as a result I get another prompt, and a infinite loop ensues :) ))

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am still not having much success in replicating this. What you will have to do narrow down the cause further. It would be best if you can get it down to just a few triggers, and the minimum of lines in the fts script. Probably the easiest way to do this is copy the fts script into another alias, then comment out sections of it, and place the script running on a continuous loop. To narrow down the triggers involved, turn on the script debugger and cause a prompt as you normally would. Get a list of everything that is run and import all that into another session. If you can replicate it in that new session with the much shorter fts script and subset of triggers then it becomes a matter of disabling triggers in that session until you are down to just the few that are required to make it happen.

Apprentice Joined: 15 Jun 2010 Posts: 121

It was only after hours of mostly guesswork I was narrow it down to this far because usually the infinite loop would crash cmud completely.. :) but I will try to simplify the fts script more and try to narrow it down with the mxp prompt trigger, since I know it fails with that one directly

Apprentice Joined: 15 Jun 2010 Posts: 121

Zugg, good news! I have narrowed down the problem to the %pathexpand function, it appears its not so thread safe... (sadly it took 2 days looking into this trying to narrow it down finally..) but I am pretty sure this is where the problem is

to test it I have a line that does in a simplified script in that separate fts thread:
#show $pathexpand($steps)

1) when it is in the script as is with the above line, I can reproduce the problem fairly easily with the same method I tested above, and in this case I see aliases being sent to the mud along with duplicate variables being created
2) when I make one change by commenting out that line the problem never reappears, and I don't see aliases command names being sent to the mud, nor are duplicate variables being created !

After repeating the problem in one session as I mentioned before at somepoint the aliases break down completely (requiring restart) and no longer work, but this time I tried for fun to test the %pathfrom and %pathexpand functions and noticed they both at this point are pretty FUBAR'd:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I can confirm a threading issue with %pathexpand.

Procedure
1. Launch CMud
2. Close Sessions window (ESC)
3. Enter at the command line