Zugg Software :: View topic - [3.16]Access violation at address 00404DCA in module 'cMUD.exe'. Read of

Beginner Joined: 30 May 2010 Posts: 18

Getting this crash at random intervals. Mostly when I'm running a fairly complex script. I'm not able to find the cause, and judging from the Script Debugger it seems to crash on random triggers. I am using a package with common triggers and aliasses i use with all chars I play and a package specific for that class. What I am noticing is that when it crashes, CMUD has made copies of variables defined in the "common" package in my class specific package. Any clue to what's causing it?

*EDIT it happens in 3.17 as well, also still noticing the variable copies being made. If i try to delete them CMUD hangs, *

Dump below:

Posted: Mon May 31, 2010 12:22 am

Without the exact script or a step-by-step procedure to reproduce the problem, there isn't much I can do with this. The crash dump indicates one or more variables have gotten corrupted. Which means you'll get errors when trying to delete them and probably multiple copies if CMUD can't access them. I suggest doing an Export All of your script to an XML file and then create a new blank session and import the XML into the new session. Especially if you have been playing with lots of beta versions that might have had bugs that caused problems in your package files.

Beginner Joined: 30 May 2010 Posts: 18

I can mail the script, let me know where to. It's a bit large to post. I did the export thing, didn't help. The error is hard to reproduce. The variables getting corrupted are fairly random. It does seem to increase a lot when I have multiple sessions open that use the same package.

Posted: Tue Jun 01, 2010 4:49 pm

It sounds too complex for me to easily reproduce here as well, especially if you are sharing it among multiple sessions.

Remember that CMUD scripting is a programming language, and like any other programming language, you can write bad code that causes problems in your scripts. You'll need to use normal debugging techniques, such as disabling certain triggers, or adding #DEBUG commands to write text to the script debugger window to try and determine which part of your script is causing the problem.

I can only treat something as a bug and try to fix it if I get a clean procedure for reproducing the problem.

Beginner Joined: 30 May 2010 Posts: 18

I have narrowed it down to a specific piece of my script. Also reproduced it in a single session. I've also traced the access violation to a previous error.

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

That's what it looks like to me.

Posted: Thu Jun 03, 2010 4:22 pm

I think Arminas is correct. When using #WAIT, you are spawning a new background thread that will now run simultaneously with the rest of your scripts. So it really depends upon what your "castspell" alias does. The "castspell" alias needs to be written with the understanding that multiple copies of that alias might be running simultaneously.

You might try converting the #WAIT to a one-shot alarm, like this:

Beginner Joined: 30 May 2010 Posts: 18

Removing the #WAIT solved the problem. Thanks for the help.

Apprentice Joined: 23 Aug 2013 Posts: 175

So in essence ANY #WA can cause this type of error? I've been seeing this error report crop up ALOT and previously had no idea why. Is there some way avoid the error without removing ALL of my #wa triggers 1 by 1?

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

The error is specifically that you made a background thread, not that you used #WAIT. #WAIT creates a background thread, but so does #RAISEEVENT (or maybe just #EVENT), other variations of the #WAIT command, and any use of the #THREAD-related commands. CMud also creates background threads on its own.

You could, of course, click the gun and computer icons to the right of the commandline so that each icon has a red X across it. This turns off everything, preventing the error from happening via your scripting but it could still happen via the internally-created threads you don't have control over.