Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

Well here it is. It's my prompt trigger.

Wizard Joined: 17 Jun 2006 Posts: 1201

Well Zugg I narrowed this down completely now.

Specifically, this is what is causing the access violation in my prompt trigger.

Using this statement:

Posted: Sat Apr 26, 2008 2:58 pm

Does it matter what the trigger pattern is when using those commands? Does it still crash even if the trigger pattern is empty? If it's not the trigger pattern, then that rules out the PCRE.DLL library.

In your example, you have a reference to $var. Is that local variable defined elsewhere in the script? Or is that the only line in the script?

I'm most interested in the first example with %pos, since %pos is a very simple function. The %match command might be trying to parse something as a pattern, but %pos is just looking for string values.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I can't seem to find a combination to replicate a crash with those lines. I am rather concerned about this since the address shown in your screen shot is in the range of the preferred space for the PCRE.DLL, and that type of crash would be consistent with the dll causing the exception.

The only thing I can think that would cause such a problem is an invalid pointer being passed into the PCRE. The only pointer the dll uses for normal write operartions is the FVector array which is held as part of the interface object. The only other time it writes to a pointer addressed space is when it has just requested and received a new pointer from the memory manager.

The error looks like a memory overwrite issue corrupting that vector pointer and may be quite hard to track down. I will see if I can add some exception handling in the dll, so that I can pass the exception up to the calling program. This would of course not be available in a future upgrade of the PCRE, but if I can do it then it should help to locate the bug long before an update of the PCRE becomes available.

I can't really see how it could be a bug in either the interface object or the dll itself without causing random crashes everywhere.

Wizard Joined: 17 Jun 2006 Posts: 1201

Wizard Joined: 17 Jun 2006 Posts: 1201

Anyone have an idea of why it is only in my prompt trigger this error happens? That trigger has priority 1.

Posted: Mon Apr 28, 2008 5:06 pm

The problem is that nobody else can reproduce this, so it's going to be hard.

Can you try changing the pattern of your Prompt trigger to something else to see if it matters what the exact pattern is? If you could determine what part of the prompt trigger pattern is causing the problem, that might help track it down.

Posted: Mon Apr 28, 2008 7:30 pm

Vijilante: Is there a "standard" compiled PCRE76.DLL somewhere on the net that OldGuy might be able to download and replace the CMUD PCRE76.DLL with to see if this problem is with our changes to it or not?

OldGuy2: If you create a new package with *only* your prompt trigger in it, does it still cause the crash in the Compatibility report?

SubAdmin Joined: 18 Nov 2001 Posts: 5187

There is a link to the a precompiled 7.0 version of pcre from the authors page http://www.pcre.org
That version should run for testing this particular issue. It is actually rather tough to find a good dll for the current version.

Posted: Mon Apr 28, 2008 10:59 pm

OK, thanks.

So OldGuy2, here is what you should try:

1) Go to http://gnuwin32.sourceforge.net/packages/pcre.htm and click on the "Binaries" link to get the PCRE binary.

2) Unpack the ZIP file to a directory on your computer. In the "bin" folder within this ZIP you will see a file called "PCRE3.DLL".

3) In your CMUD directory, rename the PCRE76.DLL file to PCRE76_orig.DLL. Then copy the PCRE3.DLL from the "bin" directory in step 2 to your CMUD directory

4) Rename the PCRE3.DLL file in your CMUD directory to PCRE76.DLL

Now try running CMUD and doing the compatibility report to see if it works any differently. Post your results.

Wizard Joined: 17 Jun 2006 Posts: 1201

Guess what that works!

Posted: Wed Apr 30, 2008 6:26 am

OK, that's very interesting. So Vijilante: any idea what might be different between the 2 DLLs that might cause this kind of problem on Windows XP?

Wizard Joined: 14 Oct 2000 Posts: 1368

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I can't find any reason for it to not fail with the other dll. Both dll's use the same set of compile options in terms of what features are turned on and how the PCRE goes about its work.

According to oldguy2's screen shot the failure point is this

Posted: Wed Apr 30, 2008 4:28 pm

OldGuy2: I'd like you to run one more test with the DLL that causes the crash (the one that comes with CMUD).

Can you create a new session and just paste the prompt trigger that causes the crash and nothing else? I need to see if it's really the prompt trigger itself that is causing the problem, or if it's some kind of memory or stack overflow being caused by the large number of other settings in your file.

Also, I *did* find one possible difference. In CMUDPro, I had increased the stack size to $00800000 based upon a recommendation from Vijilante. But I checked the regular version of CMUD and the stack size was still set at only $00100000. So this might cause a difference between CMUD and CMUDPro. If you can still get a 30-day trial for CMUDPro, give it a try and see if it works better than the regular CMUD.

Vijilante: In the Compatibility report, CMUD creates a single RegEx object and then just calls Match for each setting and each regular expression that is used to test for problems. And as you remember, one of those regular expressions *is* quite complex:

Wizard Joined: 17 Jun 2006 Posts: 1201

Well I changed back to the original dll file. I then created an empty package and pasted my prompt trigger into it and ran the compatibility report. It threw out the access violation error immediately...

So I changed back to the other dll file and ran the compatibility report and no error.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Yeah, I remember that particular regex. If it was causing a problem then I would likely see it too, since I ran the compatibilty report on all my good packages, and a fresh import of my old .mud files. My old files are rife with references to %nn and %i in quotes. They are buried deeply throughout all my scripts and if that regex was causing a problem I would have seen it.

After really examining the code for it I am figuring that it is just a bit under 1k per recursive call into the matching engine. That makes a 1Mb stack capable of handling 1100 recursions. That is rather deep. The hard limit was 10,000,000 in the default code for the dll, and I dropped the soft limit in the interface to 5,000,000 just to have it set up. Based on the change list between PCRE 7.0 and 7.6 I don't really see that the stack usage would have changed. I can always take the other dll apart and double check it.

A stack overflow still doesn't cover the statement that the compatibilty report is displaying different items as currently being examined each time the crash occurs. The only way I can imagine that, is if another thread eating just a little bit of the stack and making it over the edge every so often. That particular guess doesn't quite cover no one else replicating it, which is why I am saying it doesn't make sense.

I would definitely reccommend increasing the stack size in any case.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Do you think I could get a copy of the new package with just the prompt trigger that causes a crash?

Wizard Joined: 17 Jun 2006 Posts: 1201

Just pm'd you the trigger.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Replicated with exact addresses and it does look like a stack overflow. Some information from examining the CMud proccess while the AV is pending.

Posted: Wed Apr 30, 2008 9:40 pm

Vijilante: Does it also crash in CMUDPro? or just CMUD? If that stack difference is the problem, then 2.23 should help. But it would also be nice if we can figure out how we can trap this to prevent problems in the future. Just increasing the stack space seems like a bit of a kludge and makes me wonder if some other regex would just run into the higher stack limit.

I agree with your reasoning above that it seems pretty amazing that we would be reaching even the lower stack limit. Seems like an awful lot of recursion.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I did a curosory examination of the stack data when I captured the information for my post. The few numbers I took the time to interpret came very close to having reached the end of the string. I never quite dug deep enough to determine if it was the %nn regex from above, but all things considered it does seem likely. Since I have a replicateable data set I can try refactoring that regex a few different ways to make it run better.

I haven't checked CMudPro yet, since I have yet to install it for the first time. I will try to give it a go either just before you release 2.23 or right after. Right after is more likely since I have been blocking off the weekend for serious beta testing. Twisted Evil

Posted: Wed Apr 30, 2008 10:27 pm

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Vijilante, what do you do IRL? You seem to be far too good at all things related to CMUD Cool

SubAdmin Joined: 18 Nov 2001 Posts: 5187

My primary profession in life is surviving. My secondary profession is self amusement. It has been proven by 6th parties that amused people live longer, and the 7th party sugested CMud. I managed to perfect my primary profession in life withn about 2 seconds of birth, it was quite simple...breathe. So I took the 7th party advice and invested in CMud when I was 4 seconds old. I think it is starting to pay off.

Oh yeah. I am not paid to be funny, it amuses me to cause others to laugh at totaly inopportune moments. Thus continuing my second profession. Of course, I am not actually saying what I get paid for; since that old phrase, "What do you do for a living?", is also answered by, "Breathe."

There you have it.