llGetNextEmail() Script run-time / Bounds Check Error

There is a NASTY bug with llGetNextEmail() that causes a Bounds Check Error.

If you use the email() event as instructed on a timer, and then call llGetNextEmail() at the end of the event if there are pending emails while at the same time crossing sims the email() event is then trigged on the new sim but the memory address to the email() event variables are no longer valid. The script then immediately explodes when you try to access any of the email() event variables such as, address, message, etc.

Luckily enough there is the Bounds Checker Error in place that kills the script, otherwise one would suspect this could make the server exploitable.

It is VERY frustrating though and has held up a script Francis and I have been developing for over 4 months now! PLEASE FIX IT!

I have a script in one of my vehicles that sends and recieves email. I've been running the scripts for several months and I can't say I've seen this error. It's probably likely I will see this error eventually so I agree they should fix it.

This bug had plagued our script for months and we could not find the source of it forever. I initially had assumed it had to be a local function returning incorrectly but I went through the few functions we had in this script over and over and over and they all return nothing but booleans (as integer) in all possible execution paths. So after lots and lots of debugging I was able to pinpoint the crash to exactly to the first line where any variable from email() is referenced, but this only seems to happen as some sort of race condition when crossing sims. Otherwise the email contents are always the same and not corrupt themselves. It unfortunately affects our script a LOT due to the nature of it.

Yes! I have this same issue!

Except: I'm not using Email stuffs; only llListen() calls!

However, I do get the crash on the first instance in which the "message" string parameter is accessed.

Freaky and inconsistent, too! For some reason, I get it more frequently when there's a lot of rezzing & script interaction going on with my objects.... But there seem to be no hard-and-fast rules or guarantees. Sometimes it works, sometimes it doesn't. Frustrating as hell!

Have filed bug reports; haven't heard anything back...

Take care,

--Noel "HB" Wade
(Tread Whiplash)

This doesn't totaly supprise me. If the object is mod you could try using llRemoteLoadScriptPin to overwrite the crashed instance of the script.

Or you could have 20 instances of the *exact* same script (same guid) then when the first one crashes it *might* not take out the others.

Yes!! It was VERY hard to reproduce, I'm assuming because it is something of a race condition. Yet it would ALWAYS pop up when you weren't looking and of course not when you were. Its taken months to debug this and still no way to fix it other than resetting the script. This is an unacceptable solution, Lindens PLEASE fix this!

I'm going to take a wild guess here and say that this bug probably affects ALL event()'s when a script is handed off to another sim while actively processing an event. Sounds like a thread/race condition on the server side which could lead to an array of other problems.

This is particularly critical and should be addressed because it not only affects a small niche of moving scripts but also could affect any attachment using scripts because they too cross sims when attached to an avatar. This is bad for anyone distributing products that users are unable to reset or fix themselves when they die from a bounds check error and may be the source of many objects unexplainably dying.

If you have any simple repro case for this bug, please post it.

Dan

Probably the event queue is getting corrupted.