|
|
|
[
Permlink
| « Hide
]
Darien Caldwell added a comment - 03/Oct/08 03:31 PM - edited
This Bug should be under SVC, not VWR, but I don't see a way to change that. This could be an important clue to all the Crash issues if repeatable. I'll try to reproduce as soon as I get my neck above water.
I tried to reproduce this, but could not create the described issue.
Script called 'Email_Script': default touch_start(integer total_number) { llSay(0,"Sending Email"); llEmail("YOUR_EMAIL@WHATEVER.COM","Test Email","This is just a test."); llSay(0,"Email Suspend Done."); }} Script Called "Updater": default no_sensor() {
llOwnerSay("I can't find the object 'suspended_object'");
} } Place a copy of the "Updater" script and a copy of the "Email_Script" script into a prim called "Updater". Set the "Email_Script" to not running. To create the conditions described, touch the "suspended_object", it will send an email and suspend. While it's suspended touch the "Updater" and it will replace the suspended script with a new copy. I was unable to produce any error. well you are right and this is a little bit more complicated
I will try (with my bad english) to explain. first there is an updater object with this 3 scripts: /////////////////// updater_script default no_sensor() {
llOwnerSay("I can't find the object 'sleeptest'");
} //////////////////// sleep_script //////////////////////////////// (non running state in prim) integer LM_SLEEP = 9; //************************************************* //************************************************* nbt = 0; llMessageLinked(LINK_THIS, LM_SLEEP, "Test1", NULL_KEY); //************************************************* on_rez(integer prm) { Init(); } changed(integer change) link_message(integer sender, integer num, string str, key id) else if ( num == LM_REQUEST_NUM) /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// When rezzing the "sleeptest" object all is fine, it is calling the llSleep function, dispatching through the scripts and no error occurs in Mono and LSL complie. I hope to have been clear and that could be useful for you. I hope it is not a bug from me too I was able to reproduce the issue using your example. I"m just going to have to work on simplifying it. It's rather scary as all 10 scripts eventually crashed!
I see the difference between your example and mine, it's not the script being updated that crashed, but rather other scripts which are sleeping. A completely off the cuff guess, The sleeping scripts have pending link message events from the two other scripts. When those two scripts are updated using llRemoteLoadScriptPin(), their events are removed from the queue. But the sleeping scripts aren't informed, or miss being told this, and try to run the now missing events. Edit: nevermind about that above, other tests show no issues with events from scripts that change on the fly. I've been pretty unsuccessful at simplifying the example, simpler models don't produce the error. I"m wondering if it's a case of too many linked message events? Does the queue still drop events once it reaches the 64 event queue limit I wonder? And does Mono handle that right? Smiles, a little bit scary, but 10 was not necessary, I think 1 or 2 is enough, purpose was to minimize the time of a test and to maximize chances to get an error.
Not sure it is the 64 events queue limit (if it is still true under mono) as there is no problem when rezzing the sleeptest object from inventory to inworld, no link message is lost and I suppose there is more than 64 in 20 seconds. It is probably something around events sended by an updated, and now missing, script. Maybe a try to return to an inexistant point, in C it could be a stack error or a call to a invalid pointer, in C# I don't know. A workaround could be to call the llResetScript function just after the call to llSleep, it is hiding the bug not fixing it. Anything you can do to simplify the repro will increase the chances of a dev picking it up.
With over a dozen Mono issues, and a grabbag of other LSL JIRA, the team has to triage. All else being equal, easy to repro issues bubble up to the top of the priority queue. I went to the beta grid to check this against Server Version 1.25. At first I made sure still failed on 1.24, and it did. TPed over to a 1.25 server and re-started the experiment. I was unable to recreate the issue there.
herina, I would suggest connecting to the preview grid and trying your specific application. The sim I used which is running 1.25 is here: You can find information for connecting to the preview grid here: I'm happy to say this issue appears resolved with server version 1.25. Ah, this is a duplicate of
In the beta grid, running 1.25 server version, this error seems to be fixed
thanks to all |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||