Zugg Software :: View topic

Apprentice Joined: 03 Nov 2007 Posts: 132

In order to test the 2.x versions "readiness for release" I've actually built a system similar to what I would generally use for combat from scratch utilizing the various new features introduced in 2.x. I have discovered a multitude of bugs during this process but in the end, it still just isn't stable.

I am on a very regular basis getting "Access Violation" and "Invalid Pointer" type errors which of course pretty much break the whole thing for that time around. I still have the duplicate variable problem. I have tried so many different ways to do things to get the results I want that it's a bit silly.

My system is complex (it has to be for an IRE mud) but it is not overly so. I have attempted to keep it as "clean" as I can in terms of how it functions. I use some of the more common scripting techniques of IRE players as well as some things that are just my own.

I have gotten to the point where I'm just at a loss. Is no one else experiencing the client throwing errors on a regular basis? Is no one else having really weird problems that they can't duplicate and are at a loss to explain what's causing them? I see fewer and fewer bugs being posted to the forum (and I'm not posting many myself since I'm at the point where my bugs are so obscure I can't get to the cause of them though I can replicate them simply by putting the system under stress) but 2.x is just as unstable for my general usage as it was when I first started beta testing and I have no idea why.

At this point, what should I be doing? I know people want an exact procedure and process in order to get the error to throw but some bugs just don't work that way. I am pretty certain my problems stem from the interaction of all the various settings but I don't know what the exact combination is that is causing it. All of the settings work fine independent of one another without these annoying problems. It very well may be threading that's the problem but I've done everything I can think of to make that not a problem.

I have been working on this for weeks and have done several complete rewrites of my system. If it is only me that is having this problem when trying to run 2.x at full throttle then okay, I can just not use it and go back to 1.34 or something. But if other people are also having these problems I'm not sure how it can be considered ready for release. Chances are good the problem is on how I'm writing my scripts but is it supposed to be so completely unforgiving? Is everyone who uses this supposed to be a full time programmer in order to get it to work without problems?

I guess my question is am I alone in this frustration? If so I'll assume it is something to do with my computer and just go back to 1.34 as I am not going to buy a new computer just for 2.x.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Tue Nov 27, 2007 9:37 pm

Please remind us what version of Windows you are using. Also, how was CMUD 2.13 installed? Did you do a fresh install, or upgrade a past version?

I can understand your frustration, but I have a similar frustration with this...if you can't give more details on the problems you are having, then it is completely impossible for me to fix anything. I've been MUDding for hours and hours with 2.13 and not a single crash (it's been running for several days now without even being shut down). Now, it's true that this particular session isn't on an IRE mud, so it's not as complex as yours. But honestly, I've had a *lot* more crashes with 1.34 than I have with 2.13.

You are correct that you shouldn't need to be a full-time programmer to get this to work. In fact, full-time programmers usually have *more* problems because they are using more of the advanced features that have less testing. But it probably *is* related to something specific you are doing.

And obviously you don't need to buy a new computer for 2.x...that would just be silly. And it's probably not your computer, it's more likely to be your scripts.

So, you really just need to post more details about your scripts. Run the Compatibility Report in the Package Editor to make sure that all of your scripts are all compiled properly and don't have any problems. Then try disabling various triggers and classes to see if you can narrow down which specific scripts are causing the problem.

Also be sure you are submitting all of the crash dumps you are getting. If you cannot send the crash dumps, then play with your Internet Options settings and any proxy server to try to get it to work. I'm paying closer attention to the crash dump reports since fewer problems are being reported in the forums.

Apprentice Joined: 03 Nov 2007 Posts: 132

If I send every error report that pops up I will flood Zugg's mailbox. Also, I have been sending in reports but I have a sneaking suspicion the errors I'm getting come from the duplicate variable problem which I keep dealing with and the root of the problem (the duplicate variables) remains an elusive bug.

Posted: Tue Nov 27, 2007 9:40 pm

Apprentice Joined: 03 Nov 2007 Posts: 132

I am not really certain what more details I can post with just posting the package and honestly, I don't want to post the package publically as I don't really want to deal with people exploiting the system in combat. I have run the compatibility report. Everything compiles perfectly. I have gone through every single trigger/class with everything else disabled, it all works fine on its own.

The problems arise when multiple threads and settings are running at once. For example if I need to be sipping health, eating an herb, applying a salve, changing my parrying, and switching my stance all within about 1-2 seconds of one another the chance of the problem striking is very very high. All of the scripts detailing the need for these things are suitably complex so the client is doing a lot of processing in a very short period of time on several different threads with alarms nesting somewhere in there.

I can't get it to happen reliably but that it *will* happen is a given. The debugger text I get is not helping me track it down any more specifically than this.

I will start sending all my crash dumps and see if that helps to narrow down the problem.

Apprentice Joined: 03 Nov 2007 Posts: 132

Posted: Tue Nov 27, 2007 9:53 pm

I'm sure Zugg would prefer to have a mailbox flooded with bug reports than he'd have a program flooded with bugs he can't fix, and I'm sure that everyone else would prefer that too.

One other thing you could try is that if you can reproduce your problems on another computer (even if you have to copy the files around to make that happen) then you can upload or email the files to Zugg with a procedure to get it working on a new computer. That way he can hopefully track down the bug himself once he can see it happening.

Posted: Tue Nov 27, 2007 10:08 pm

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I understand the frustration you feel and sympathize. If you look back through the beta forum just a little ways you will find I was awfully silent for a very long time. I couldn't get CMud to import my existing scripts and do some very basic cleanup and rearranging with them. I think it was version 2.05 or 2.06 when I finally had my life in order enough to really start properly reporting bugs, and at that point I started reporting around 10 bugs each version just in importing and moving settings around. I am sure if you look hard enough you will find a few posts where my personal frustration became evident in my typing.

We have all been where you are at some point. I keep a small stack of notes about things that didn't quite seem right and restest a few each version. Some bugs really need many more eyes to look for them. Posting about noticing something wierd and asking for help in spotting it is not a bad thing. For example I have 2 such things out there right now, a full lockup and %numparam failing. These are items that I can't find a way to make happen, but they did and shouldn't have which means they are bugs.

You have posted quite a few very odd problems, and I can't actually recall anyone here finding that your scripts are at fault. It took some time but YOU finally found the behavior in Vista that none of us knew about, and was the cause of quite a bit of trouble. That success alone provides Zugg with knowledge of what to change to make CMud better for everyone that uses it with Vista. This literally means that your find has helped thousands of users. Such a find dwarfs a thousand reports about obscure commands and syntaxes that no one ever uses.

Please, don't ever sell yourself short. Reports of strange things often provide clues about things to test. Some of the bugs that have been posted in the last few versions couldn't even be found until another bug was fixed. I realize you are hitting hard crashes that don't even allow a crash dump report. Those kind of crashes are not even supposed to be possible, so you are running into the deepest levels of bugs. The rest of use are still stuck peeling away one layer at a time.

Apprentice Joined: 03 Nov 2007 Posts: 132

I will try the exporting and reimporting and see if the problems continue. It's quite possible the package is corrupted given the number of memory problems I've had. If they do keep on, I'll bundle up the package and some instructions and send it over.

Posted: Tue Nov 27, 2007 10:31 pm

One approach to create a new package, that may help a bit to export you code to XML then reimport it. CMUD will likely break on re-import if something is really hosed.

[Edit] Ninja'd big time.

Posted: Wed Nov 28, 2007 12:24 am

Also, unfortunately, the reality is that I'm going to be forced to release a public version just to get more people to find bugs. For a program as complex as CMUD, we just don't have enough people doing beta testing right now. This has been true for a long time. You'll often see that right after the first public version release there are a lot of new problems reported that were not discovered in beta testing.

The automated crash dump system really helps with this. When we get more people using it, I get more crash dumps and it often helps me determine if there is a particular routine that is causing a lot of the crashes. But this kind of "statistical" bug analysis requires a lot of users.

Anyway, definitely help as much as you can, but don't stress over it. Last year the first public version was 1.24. We had 10 more versions until 1.34, and 1.34 still contained a *lot* of known bugs. So I know that 2.14 (or 2.15 or whatever the public version ends up being) isn't going to be "perfect" either. But hopefully it will be good enough for the majority of people using it over the holidays.

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

Posted: Wed Nov 28, 2007 5:16 am

Matt is correct. I keep trying to remind myself that data "corruption" is the wrong word to use. For example, in one of the past beta versions, you could get a setting created where it's "module" reference (normally the record ID of the module/window containing the setting) would be set wrong. The "parent" reference (points to the class containing the setting) would point to a class that was in a different module. The setting would still be displayed within the given "parent" class, but since the "module" field was wrong, CMUD would think that it was a member of a different module/window. So in this case, the database itself wasn't "corrupted", but some of the data pointers were wrong. The latest version of CMUD automatically fixes this specific example, but that's the kind of thing we are really talking about when I say "corrupted"...totally different than the bad file corruption that could happen in zMUD causing all of your settings to be lost.

Adept Joined: 04 Feb 2005 Posts: 246

I don't get the impression that lots of people are getting such frequent runtime exceptions, so here's a stab in the dark.... Are you doing anything that tries to take advantage of the multi-threading features?

Inexplicable crashes are a trademark of race conditions in the internal code.

I probably can't be more of a help, since I am still using zMUD for my real gaming.

Apprentice Joined: 03 Nov 2007 Posts: 132

Here's another long post on the subject:

I was able to export and reimport my settings into a clean package using xml with few problems. I might make a topic on how importing handles modules (i.e. if a module already exists and you're importing another class with the same module, does the module really need to get created again?) but otherwise, everything worked smoothly. Which is very nice to know!

Unfortunately, I had the same problems with the clean package as I did with the old one. So I was getting ready to send the package over to Zugg and trying to determine how best for him to test it to get these errors. As I was playing around offline (and getting the errors almost constantly with the combination of tests I was running) it was a lot easier to read the debugger and I could see more clearly what I suspected and suggested before - that the problems were coming about due to the interaction of multiple complex threads executing in close proximity of one another (time wise). I had three main alarms. One was to cure my afflictions. One was to manage my health/mana/etc.. The third was to handle my parrying and stancing. The curing of afflictions doesn't have any shared global resources with the parrying/stancing or health/mana/etc. but the parrying/stancing and health/mana/etc. do share a couple of functions and variables. Here is a debugger output when a couple of them are going at the same time:

0.0852 | c Lusterni | [57] Lusternia Trigger : start : Alarm "CureAlarm" : #IF (%numitems(@AfflictionList) > 0) ...
0.0000 | f Lusterni | Alarm: *0.7
0.0145 | c Lusterni | [60] Lusternia Trigger : start : Alarm "WoundAlarm" : #IF (@CurrentWounds > 0) {#CALL @sor...
0.0000 | k Lusterni | [57] Var "lastpipe" changed from "ColtPipe" to "MyrPipe"
0.0043 | k Lusterni | [60] Var "WoundPercents" changed from "blah" to "otherblah"
0.0000 | k Lusterni | [60] Var "NeedParry" changed from "" to "larm"
0.0046 | d Lusterni | [60] Lusternia Trigger : stopped
0.0006 | d Lusterni | [57] Lusternia Trigger : stopped
0.0058 | d Lusterni | [57] Lusternia Trigger : terminated

This is what it would normally look like while running. I'm not really certain why [57] was terminated as well as stopped but I don't really fully understand the stopping vs. terminating. I know when it throws an error and I click continue, I'll get a lot of terminated threads as opposed to stopped.

Here is what it would look like when an error was thrown:

0.0924 | c Lusterni | [7] Lusternia Trigger : start : Alarm "CureAlarm" : #IF (%numitems(@AfflictionList) > 0) ...
0.0000 | f Lusterni | Alarm: *0.7
0.0150 | c Lusterni | [11] Lusternia Trigger : start : Alarm "WoundAlarm" : #IF (@CurrentWounds > 0) {#CALL @sor...
0.0097 | j Lusterni >eat marjoram
0.0041 | k Lusterni | [7] Var "lastherb" changed from "" to "marjoram"
0.0005 | f Lusterni | Alarm: *0.7
0.6625 | c Lusterni | [12] Lusternia Trigger : start : Alarm "CureAlarm" : #IF (%numitems(@AfflictionList) > 0) ...
0.0001 | f Lusterni | Alarm: *0.7
0.0176 | c Lusterni | [13] Lusternia Trigger : start : Alarm "WoundAlarm" : #IF (@CurrentWounds > 0) {#CALL @sor...

Then after the error is thrown and I continue on it looks like this

0.0049 | d Lusterni | [16] Lusternia Trigger : stopped
0.0006 | d Lusterni | [15] Lusternia Trigger : stopped
0.0001 | d Lusterni | [11] Lusternia Trigger : stopped
0.0002 | d Lusterni | [7] Lusternia Trigger : stopped
0.0006 | d Lusterni |[15] Lusternia Trigger : terminated
0.0008 | d Lusterni |[11] Lusternia Trigger : terminated
0.0001 | d Lusterni |[7] Lusternia Trigger : terminated

In this particular setup, I did not have critical sections put around anything. But one problem is readily visible. Even though the CureAlarm and the WoundAlarm are still running, as soon as they hit their time to run again, they're running anyway. This could cause quite a few of the same named alarms to be running at the same time. However, I am not positive that this is what is actually causing the duplicates. As can be seen there was a 6/10th of a second delay between one of the alarms being called and it actually starting. This is where the access violation error was thrown. Why was it thrown? I can't really know. Perhaps the woundalarm was trying to access the same variables that were being accessed by another thread. However my understanding was that both trying to access the same variables would not be so problematic. That the problems would be in both trying to write to the same variables at the same time. Which neither of these were trying to do. Regardless, could two different threads both trying to access the same global resources in parallel cause these sorts of errors? I will try to test that theory a bit later.

So I put into place the proper #SECTIONs in this code. Well, proper as far as I understand it anyway. I tried a few different things. First I tried placing them around the code that was enabling the alarms. That had no real effect. Then I tried placing them around the alarm code itself. This worked and the AV errors disappeared. Unfortunately after a period of time I would get hard lockups and have to shut down the system. I am not certain where else I can place the sections to stop attempts to access the same resources at the same time.

Anyway, I decided that since the problem seemed to be happening primarily when several different complex alarm threads were running at once, I would combine all three into just one alarm. I did that and it works like a charm. I have not gotten an AV error or hard lockup since running the same tests that caused them reliably in the old setup. I HAVE gotten a duplicate variable error which caused a function a misfire. This occurred when I was manually removing an item from a list on the command line while a thread was running in the background that was reading from that list. We will see what other problems crop up with this setup.

I still have the old package setup saved with the testing setup and ready to go if you still want to take a look at it Zugg. From my understanding the duplicate variables should really never be happening and this many access violations and crashes shouldn't really be caused just from having multiple threads reading from the same global resource.

Sorcerer Joined: 13 Jan 2006 Posts: 715

I for one think you should send the package to Zugg for the simple reason that A LOT of people use multiple alarms in similar manner. Including me. Lets fix this now, so it isn't an issue.

Posted: Wed Nov 28, 2007 5:58 pm

Thanks for posting all of those extra details...they really help.

In the above example, is a duplicate variable being created? And if so, is it a variable that is being accessed by one or both alarms?

You are correct that it looks like your alarms are all running multiple times. I can definitely see that if you have an alarm that takes too long then it can fire again and get multiple copies running. zMUD wouldn't do this...it would delay the alarm execution until the previous alarm was finished. Looks like CMUD is allowing alarm timers to be processed while other scripts are running.

Btw, the timestamps shown in the debugger in v2.13 are incorrect. They are actually off by one line. So the 0.6625 delay was actually for the *previous* line. This timestamp problem is fixed for 2.14.

Apprentice Joined: 03 Nov 2007 Posts: 132

I don't believe in that particular example that a duplicate was created. Also, when they are created, they seem pretty "random" in terms of the duplicate. It almost seems like if the condition exists for the duplicates to be made then any variable that is updated while that condition exists can be duplicated though I may be incorrect in that. Because the problem isn't consistent and I can't always see where exactly the script is in terms of processing (I can't see when functions execute for example and I use quite a few functions) I am not positive what variables are being accessed at any given time.

But I do have a very reliable method to get the errors on my old package now though I can't pinpoint the cause. If you want it.

Posted: Wed Nov 28, 2007 7:42 pm

What I was trying to clarify is whether the duplicate variables are variables that you are "setting" or just "retrieving". I'm assuming they are variables that you are setting the value of within one or more triggers?

Apprentice Joined: 03 Nov 2007 Posts: 132

Yes, they are variables that are being set. None of my read-only variables have been duplicated as of yet. (knock on wood)

Apprentice Joined: 03 Nov 2007 Posts: 132

So I still get the access violations with the new setup. Just not quite as often and not as crippling. I have a few questions though.

What is the strictness of cmud on variable types and using functions meant for one variable type on a different variable type. For example if I used LOOPDB on a stringlist or FORALL on a database record? Would that matter to cmud?

Posted: Thu Nov 29, 2007 8:50 pm

Since a database record in CMUD is actually a string list (or the form key1=value1|key2=value2...) then you *can* use #FORALL on a database variable. You would get %i set to "key1=value1" and then "key2=value2" just like you'd expect.

If you tried to use #LOOPDB on a stringlist, it should loop through each item in the list and assign %key to each item, but will have %val empty for each item.

The CMUD typing is still not completely strict. It will still try to do what you expect it to in most cases.

Apprentice Joined: 03 Nov 2007 Posts: 132

Okay. Well so much for that idea!

Should variables have a priority assigned to them? I notice in my old package they all do but when I export it to xml and reimport none of them do.