Zugg Software :: View topic - Getting lots of strange "bugs" and errors, what are my options?

Apprentice Joined: 24 Jul 2008 Posts: 109

I've posted a lot over the past two weeks or so about weird, inconsistent "bugs" and errors I've been getting. For the most part, other people do not seem to have these problems and do not seem to be able to replicate them. I'm going crazy trying to figure out what might be causing all this, so I'm looking for any advice, any ideas, anything about why this is going on, and hopefully what I can do to fix it. And I do mean anything, as in: hardware problem, possible conflict with other software, trying to do something that isn't actually allowed but for some reason doesn't always error the program immediately, etc.

Here are things I've already tried:
- testing my RAM for errors. Did this twice, it checks out. Other programs aren't doing anything weird, besides.
- uninstalling and reinstalling CMUD. Did this twice as well, once after 2.34 and once after 2.35. Each time I backed up my sessions, then restored them. Didn't change anything.
- exporting my session to XML, deleting the session, recreating it, and then importing from XML. This made things far worse, to the point that the program crashes when I run an alias. I restored from a backup.
- I am always careful to close and reopen CMUD as soon as I get any sort of error message, to make sure subsequent errors aren't just residual weirdness stuck in the program. Everything listed below is the first obvious error to occur any given time I open CMUD.

Here is a list of the weird stuff that has been happening:
- Events randomly aborting, while identical aliases do not. The events generate errors if I try to raise them a few times, too. (Post)
- Events in general just never work correctly. This includes the preset events. For example, I have an OnExit that works maybe 80% of the time. I'm not counting the time the program errors and I must exit, because I don't expect it to catch that.
- Triggers will sometimes not fire, for no apparent reason. With some triggers, they will consistently not fire. (Post) With others, it's random. For example, I have a trigger that should fire off "You finish humming" and there is no trigger that is at all similar, and it doesn't even have a name to get mixed up with anything else. There's not even any special pattern matching characters in this pattern. Still, it will fire only about half the time. I always check that it and its class and any parent classes are enabled, and it is. I always check the line in the trigger tester, and it works. I have seen this happen with other triggers, too.
- Sometimes triggers are not created in the class I tell them to be created. Zugg's answer about special characters, and triggers longer than 64 characters was helpful, but then later I noticed this happening with short patterns with no special characters too. I got around this by using T+ and T-, which admittedly are better for what I want to do anyway. Still, this isn't supposed to happen. Since it is inconsistent as well (sometimes works, sometimes doesn't, always a different trigger) I'm listing it only as evidence that something weird is going on. (Post)
- Sometimes I will make changes to an alias or a variable when nothing is running, and hit save. It will run the alias as it was before I saved it, or use the value the variable had before I saved it. Then, if I run the alias a second time, or access the variable a second time, it will run with the changes I made. This is really weird and has only happened maybe three instances that I had CMUD open.
- The mapper is error-city. If I open it, I will get an error within at least ten seconds. After the first error, I pretty much get spammed consistently with more errors. Sometimes the errors are one right after the other and crash the program. Sometimes I just get an error every five seconds or so. This is the case regardless of whether I have a map loaded or not.
- I can load the mapper, stay in follow mode, make no changes, and close it, and when I open it again, sometimes links will spontaneously have changed.
- There is always at least one random room that will hang when speedwalking in the mapper. This room is a different room every instance I open CMUD. Sometimes it only hangs in one direction. Sometimes it hangs in all directions. I always double check the room name and description against what is saved for the room, and there is always no discrepancy. I always copy and paste the name and description in over the old stuff just to be sure, and this never helps. I always try to delete and automatically redetect the room, and it will still hang after I have done so.
- Since 2.34, a gauge no longer refreshes properly. Whether it refreshes or not is entirely sporadic. (Post)
- As noted earlier, importing from XML in hopes that maybe my session was just messed up somehow made things far worse. It does weird things like spam infinite commands to CMUD all at once because it ignores #WAITFORs in a loop, for example. (Post)

I probably don't even remember all of it right off the bat, but I'll update it as needed.

Is weirdness like this indicative of something in particular? :-/ Is there anything at all that might cause these kinds of problems?

I'm getting pretty desperate here. At the end of this month I will be able to try CMUD on a different computer, which should be able to rule out if it's just some weird thing with this particular computer. However, in the meantime my trial will expire and as much as I would like to buy CMUD, there's no point if I can't fix what's making it go crazy. I don't want to use another client, though, since the stretches of time where I've been lucky to have it work without weird bugs, it's been great. It seems there must be something causing all this and if I could fix it everything would be great, but identifying it seems to be difficult since no one's figured it out yet.

If anyone figures it out, I will be extremely grateful. Thanks. :-/

Wizard Joined: 14 Aug 2004 Posts: 1269

Can you try your settings on another computer now? Or even run Windows in a virtual machine (VMWare Server or MS Virtual PC) on your existing computer? Or as someone suggested in another thread, on crossover Linux (etc.) as you seem to use Linux too? What O/S are you using at the moment? (including edition and service pack level)

If not, could you try a trial of zMUD until your new computer arrives?

Apprentice Joined: 24 Jul 2008 Posts: 109

The only computer I have at the moment is this one. :-/ Explanation: My fiance and I moved out of state temporarily, and just bothered to take his computer and my EEE PC since we were strapped for space in the car. So I'm using his computer for now. The EEE PC definitely isn't capable of running CMUD, just because of its hardware. But we're moving back at the end of the month, to where my desktop computer is.

I'm using Windows XP Pro 32bit, Service Pack... huh, 2. There's a 3, right? I'm having a vague recollection of my fiance complaining because the Windows Updater wouldn't actually download SP3. Might that be part of the problem? We could download and install it manually. So there's one option.

Linux is also on this computer, the latest version of Ubuntu, 8.something. (I don't know offhand because I'm in Windows atm, but we updated just yesterday.) I'm gonna give VMWare a go, and failing that, CrossOver. I'll update about how that goes when I can do it later tonight.

Thank you for the suggestions!

Wizard Joined: 14 Aug 2004 Posts: 1269

OK, XP SP3 is probably more likely to have issues than SP2, so don't hurry to upgrade for the sake of CMUD (unless you think Windows is broken since the upgrade might fix it, but it would still probably be better to do a repair on it first in that instance anyway).

Wizard Joined: 17 Jun 2006 Posts: 1201

SP3 on Windows XP Professional doesn't cause any problems. I've had it for awhile.

Wizard Joined: 14 Aug 2004 Posts: 1269

Good to know.

Apprentice Joined: 24 Jul 2008 Posts: 109

Okay, here's what I have to report...

VMWare - Could only use this to replicate the existing version of Windows on the computer right now, because we don't have the install disks here for Windows to do a clean version. So this does not seem like it would give any helpful information.

CrossOver - Could not even install CMUD 2.35. Once I get through selecting directories and it starts installing, it gets about 75% through and then gives the error: "Access violation at 0x7BC6EEF7 (tried to read from 0x00000010), program terminated." We can't figure out a way around this, so we can't test it in CrossOver. (Yes, we did install IE6 in CrossOver before trying CMUD.)

WINE - It just ran really buggy from the get-go, before I even bothered with sessions. The graphics on the icons were messed up, deleting the pre-set sessions was acting strangely, etc. I copied over my session folder and made the session, but it gave an error about something like the English something or other not being a valid SQLite Database. It never did even open the session, offline or otherwise. I just got an untitled window, moving windows around was borked, and then it was all very buggy and freeze-y anyway. So it doesn't seem like we can get it working in WINE to test anything.

So right now it doesn't look like I have another computer or OS to test this on. :-/

If XML importing worked in 2.35, I would be able to determine if my session is messed up, correct? I could just delete my session and import from XML. Presumably the thing about it not importing completely in 2.35 is why my imported session was completely unusable. So one thing I could do is wait for the next version of CMUD where XML importing works again, right? And then I'd know if it's that my session got messed up somehow?

Depending on what information that gives me, or if that doesn't happen before the end of the month, I will be able to test on a different computer. So that should give some information, either way.

Anything else I'm neglecting? Any other ideas in the meantime? Thanks. :-)

Wizard Joined: 14 Aug 2004 Posts: 1269

Well you could try XP SP3 since the other options seem exhausted... It might fix something that might have got screwed up in your system.

Posted: Tue Aug 12, 2008 5:00 pm

Your various problems don't actually sound like Windows problems to me. It sounds more like you have a script stuck in the background that is messing up other stuff that is running. I don't know how complex your scripts are, but if you have complex scripts then they might be interferring with each other.

Try running the #THREAD command to see if you have multiple script threads running at the same time that might interfere.

Also try disabling your triggers and then enable them one by one to try and determine which one might be causing problems.

You can also run the Script Debugger in the Window menu to see exactly what scripts are running from exactly what text is received from the MUD.

And yes, you might need to wait until the XML import problem is fixed. It's very possible your packages have gotten corrupted and XML export/import is about the only way to repair that.

Apprentice Joined: 24 Jul 2008 Posts: 109

I always check out #THREAD and there is only a single thread running. It should be the case that there is always a single thread running even if I'm not running any scripts, right? (If not, that would definitely be the problem because I always have at least one thread showing up.)

My scripts are too terribly complicated but they do rely on an alias called "queue" that keeps a queue of commands to send the game... So they also all refer to a variable called "t" which controls how much time I must wait. (Many actions in the game have a time -- in seconds -- associated with them, so you cannot perform another action until that much time has passed.) I've wondered if that has something to do with the issues, but I also had strange errors before I set that up.

I will try out the script debugger and see what happens. I have a ton of triggers but I know which ones I set up long after I started getting errors, so I can probably narrow it down more easily.

Thanks!

Posted: Tue Aug 12, 2008 5:17 pm

One thing that might be happening...

You said that your script will just abort in the middle. Like it doesn't wait for the #WAITFOR command? Well, CMUD can only wait using the #WAITFOR command if it *is* running in a thread. CMUD tries to be smart and only creates a new thread when it thinks that it needs one. So it checks your compiled code for any #WAITxxx commands. If a #WAITFOR is found, then it runs your script as a thread and then properly waits for the text from the MUD.

So it's possible that you are somehow fooling CMUD and that CMUD doesn't detect your #WAITFOR command. Using #EXECUTE might cause this, since CMUD has no idea in advance what you are executing with #WAITFOR. It's also possible that there is still a bug where CMUD doesn't detect a #WAITFOR command nested within another alias or event or something like that.

Maybe someone can condense this down to something simpler that I can test here to see what the problem might be.

Apprentice Joined: 24 Jul 2008 Posts: 109

I took out all #EXECUTEs in everything except for this one:

#EXECUTE %item(@rtqueue, 1)

There's no other way I could rephrase that without using #EXECUTE, right?

Events still spontaneously abort now (I put details in that forum thread) but they just error immediately.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Tue Aug 12, 2008 7:38 pm

Depends on whether @rtqueue contains text to send to the MUD, or whether it contains CMUD scripting commands. If you just want to send the result to the MUD, then definitely use #SEND instead of #EXECUTE. Only use #EXECUTE if the @rtqueue contains an alias or other CMUD scripting command that you want to execute.

Apprentice Joined: 24 Jul 2008 Posts: 109

Thank you, I replaced it with #SEND now. :-)

I'm still testing things, but on the whole it seems a LOT more stable now that I'm not using #EXECUTEs. :-) Thanks! I'm going to revisit some old stuff and see if some specific bugs have gone away.

Apprentice Joined: 24 Jul 2008 Posts: 109

Okay, an update...

After I replaced the #EXECUTEs with #SENDs, it got rid of some strange things but others just cropped up in their place. For example, my gauge always updated properly after I changed stuff to #SEND. However, all these things started happening:

- Sometimes when I would boot CMUD, that same gauge's color would change to grey from red. Sometimes when I changed it back, it would stay the next session. Sometimes it would go back to grey again.

- Still had errors with things not triggering half the time, and triggering the other half.

- A button I made to execute an alias -- its script text was just the alias's name -- would freeze CMUD... sort of. It didn't go completely nonresponsive, just putting other program windows on top would sear those windows onto the session's window, so when I'd try to bring CMUD to the front I couldn't actually see the session window, just these frozen bits from my browser and such. (You know what I mean? This sort of thing happens a lot when any program freezes.) Right clicking on CMUD in the taskbar would update the window a tick, by which I mean it would "freeze" immediately after , but if I kept spam-clicking it, it would update a little each click. I would always have to close CMUD. The button did this consistently every time, except for the session in which I made the button. During the session in which I made the button, it worked perfectly.

Typing the alias name did not freeze CMUD. Another button that did a different alias would not freeze CMUD.

- I began to notice that it was a common theme that something would work perfectly the session I made it, but after closing CMUD and re-opening it, it would give me weird errors -- either pop-up errors, or it would freeze the program, or after running an alias a few times I would sometimes get errors echoed in the session window. That made me think maybe my session really is messed up, since the problems seem to have something to do with it opening it oddly, or maybe it's saving it oddly when the program closes, or something.

I should note that every time something weird like this happened, I would #THREAD and there would be nothing running that should not be running. Except, of course, when the program would freeze up I couldn't enter anything, not even #THREAD.

- Another weird "bug," which I will talk about below.

So today I saw that 2.36 was out, and the XML import had been fixed. I exported my session to XML. I completely uninstalled CMUD, backed up my session folder, and deleted the original CMUD folder under My Games. I installed 2.36. I imported my session from XML.

So far, things seem better but I probably need a full day or two of testing to know for sure. (My trial ends tomorrow and I'm on the fence about buying it before I can try it on my other computer to see if it works any better, but that would be after the 23rd or so. So if I don't say anything until after then, that's why.) Right now, I haven't had the gauge color change to grey yet. I haven't seen it miss a trigger yet. I haven't gotten a pop-up error yet. However, I have only done one session so far. I'm wondering if it will start erroring next session, but I don't have much time to test today.

And the "weird bug" I mentioned above is still present.

Details about the weird bug: In the game I play, some actions have times (in seconds) associated with them, so you enter the action and then have to wait that amount of time before you can do another action. I have a trigger that reads in how much time I need to wait, an alias called "queue" which adds an action to a string variable that is the queue of all the actions I want to perform, and an alias called "emptyqueue" that sends an action to the game whenever the wait time is up. In other words, it detects how much time I need to wait, adds actions to the queue, and when I don't have to wait, it sends an action. So my scripts and triggers basically have a lot of lines that read "queue whatever" where whatever is the action I want to perform. In fact, any action I send to the game must go through the queue first.

Needless to say, if there is something weird with my queue and emptyqueue aliases, that would definitely be the prime suspect for lots of the errors I'm getting. I've posted these in other threads but no one has remarked that they notice anything particularly weird. I'm posting them here again just in case, and because it's necessary to explain the weird bug I'm getting. So here are all the relevant things before I move on:

The trigger that reads in how much time I must wait. It triggers off anything that says "Roundtime: # seconds" or "Roundtime # seconds" where # is a number. It does the #SHOW T IS SET. because sometimes I would tell the game to wait for "Roundtime" before moving on in a script, but it would try to do a command before the trigger had read in the time to @t. So instead, I tell it to wait for "T IS SET." which always comes after a "Roundtime" -- then I know that @t has a value and it can move on.

Enchanter Joined: 09 Sep 2007 Posts: 605

Apprentice Joined: 24 Jul 2008 Posts: 109

I wondered if it was something like that, but now I'm even more confused...

I thought that CMUD would run those aliases each in a new thread when it got to things like that. In fact, that had been my experience before, but now I don't know if that's just a larger part of CMUD acting strangely for me or not. For example, when I would tell it to start an alias within another alias, it would always start the alias as another thread. That alias would run while the other alias continued running, i.e. it would be sending commands from both aliases simultaneously. Is this not supposed to happen? Am I supposed to enter something to specifically tell it to start something as another thread? If so, is it a bug that CMUD has always done this for me automatically?

One of the reasons I was upset about events always spontaneously aborting on me was when I did some tests with an alias that raised several events in a row, it would do so consecutively -- it would raise and complete one event, return to the alias, raise and complete the next event, return to the alias, then the next event, and so on, rather than running them all at the same time. For some circumstances, I didn't want to deal with aliases running parallel but I couldn't make my aliases into events without CMUD having crazy errors, so I just had to deal with the aliases executing at the same time. Are aliases not supposed to execute at the same time unless I say so? If so, why do mine almost always do that? :-/

In other words, since aliases have always done this for me, I expected the zkill alias to hit "queue jab" and run the queue alias in a thread parallel to the zkill thread. And while that was running to continue on to the "queue kick" and run that as its own thread, and so on... resulting in the near-immediate value of jab|kick|jab|kick|jab|kick|jab|kick|jab|kick for @rtqueue.

And I'm still confused as to why it broke my ability to enter aliases into the command line altogether when I interrupt the one alias... :-/

Wizard Joined: 22 Mar 2007 Posts: 2320

Enchanter Joined: 09 Sep 2007 Posts: 605

Apprentice Joined: 24 Jul 2008 Posts: 109

Okay, I have my other computer now and I have CMUD installed on it. I have just recently gotten some time to mess around with stuff. Here is what I know so far:

- I have pretty much the same problems on this computer. I have less errors since importing from XML, so it is reasonable to deduce that I had some corruption in my session. However, since I get these other problems still, there must be either be a problem in my coding (likely) or else bugs with CMUD. I'm looking more closely at some things to figure out what's up.

- I am looking at the queue system in particular. Which commands will automatically execute in a separate thread? This in particular is what really gets me, because before importing from XML CMUD would always, always just run all the queue aliases without waiting for the last queue alias to end. Obviously this had something to do with my session being messed up, I just don't know what to make of it. I'm going to try and see if I can get it to do it again.

- I don't quite understand why it would be a huge deal for a stringlist variable to be modified by a few things at once... Practically speaking, it only deals with entering and deleting whatever is in the first slot, so it doesn't matter to me if other things get added in the other slots in an imperfect order. As far as the program is concerned, though, does it not work like this? If it is a big problem, is there any way I can keep a queue of commands without that being a concern? It's pretty necessary to the game I play, and if I can't do it it defeats my purpose for using CMUD. :-/

- The big problem I'm having at the moment is triggers either not triggering, or a trigger triggering more than once off the same full line. I do not have the box checked for it to trigger more than once off a line.

I'm going to make another session with only each alias and the triggers associated with it, and try them out one at a time. It might take a while, though.

Apprentice Joined: 24 Jul 2008 Posts: 109

Hmm, re: making sure the variable doesn't get accessed by multiple threads simultaneously, I reread the #SECTION info and made these changes to the queue and emptyqueue aliases... it appears to work, but did I put the #SECTION in the right place to ensure that?

queue:

Posted: Thu Aug 28, 2008 8:05 pm

Posted: Thu Aug 28, 2008 8:10 pm

Is there a reason why you are doing:

Apprentice Joined: 24 Jul 2008 Posts: 109

Ahh, thank you for the explanation of the stuff trying to access the memory at once. :-) That makes sense to me that the threading would have been weird in my corrupted session, too.

I will definitely try to get some more solid stuff to show you (game text along with my triggers). I just started running the debugger a bit more today; that's how I caught the same trigger triggering more than once off a line. I'm trying to duplicate it, but of course whenever I do that it decides to behave. :( I'm pretty sure I'll get examples by the end of the day, though, unless real life intrudes this evening (which it might).

I think that one cause of my triggers not triggering when they should is that some of them began with ^, and the game will mess up sometimes and display a line from the game next to the prompt character, which is normally just for commands I've sent to the game. I caught this happen a few times today... I have a trigger that will trigger off "^You finish humming" and it wasn't triggering off the game displaying "> You finish humming." So I took the ^ out -- it wasn't crucial anyway -- and it hasn't messed up yet. That's definitely just the game itself messing up, too, because it does that in other clients.

Oh, to answer your question about the additem stuff... because I got the idea for the queue, and the bare bones of it, from an old (I think) ZMUD post for the game I play. :-) That's how they'd written it and I just never stopped to think about it. I'll go change that right now, thanks!

It's funny you apologized because I think you're being very helpful, not neglectful, haha. I really appreciate it!