Zugg Software :: View topic

Posted: Sat Jun 28, 2008 4:52 pm

I'm getting this access violation and I'm not sure why. It occurs when I run the code below, but it won't happen every time. If I've newly opened Cmud it won't occur, but if it is called after I've been running a while it will give this error.

Posted: Tue Jul 01, 2008 5:09 pm

I was not able to reproduce this. What are you doing when the error occurs? The stack-dump above looks like it crashes when trying to create a new trigger, and none of the code you posted has anything in it to create a new trigger, so I think the problem is occuring in some other script.

Posted: Tue Jul 01, 2008 11:50 pm

This is part of code that reads in a list of vials and then sorts them by putting them in my pack and then taking them out in a specified order so that they are now sorted in my inventory.

When I tested this I thought I had narrowed down the point of failure to this section. You said from the crash report it looks like it is happening when it tries to create a new trigger, and isn't that what the #alarm statement is doing (creating a one time trigger that executes 2 seconds from the present time)?

Posted: Tue Jul 01, 2008 11:58 pm

Here's the rest of the code. I don't see anything else in here that would create a trigger other than the #alarm from the previous post:

Posted: Wed Jul 02, 2008 1:06 am

Yes, the #alarm command creates a new trigger, so it might be that. I missed that in your original post, but will give that a try.

Posted: Wed Jul 02, 2008 4:05 pm

I was getting the error again, so noting you said it was a trigger creation I changed the #alarm statement to make it a permanent alarm trigger that is enabled with #T+ and auto-disables itself. That fixed it so I don't get the AV anymore. However I still don't have an answer as to exactly how that #alarm was causing it. In fact I have alarms in many different places and it never causes issues. Add to my confusion that I never see the AV after just starting CMud, I have to have been playing for a while and then use that code to get it. Very odd.

Posted: Thu Jul 03, 2008 11:08 pm

I saw you fixed this in the release notes, amazing. I didn't think I had given nearly enough information for this to be reproduced repeatably...

Posted: Thu Jul 03, 2008 11:34 pm

Well, I *think* it is fixed. What I fixed is a line that might cause an access violation in some cases. But the problem was that it normally shouldn't happen. To trigger the access violation, a cached pointer had to be nil, which means that there is a corrupted setting somewhere. However, it *might* be caused by an alarm (or temp trigger) that removes itself (setting it's pointer to nil) while another script is running. So I went ahead and added a check for the nil pointer to fix the access violation.

(In other words, I never actually "reproduced" the crash, I just used your crash dump info to find the line in the code that I needed to look at)

What I'm saying is that by "fixing" this access violation, I might have just moved the potential problem later into your script. So you might get a new access violation somewhere else now. But give it a try and let me know.