Potential showstopping bug on many mainland regions. Anyone else experienced this?

[Ample Clarity]

There's a bug on the server update - there is an event in scripting, it is triggered as soon as a script rezzes an object - and with the server update it seems that event is not triggered correctly anymore -  I put a message into that event right at start to see when it triggers - the message never appears

 

 

 

"On Tuesday, March 4th:

• Around 30% of the total grid (equivalent to the 3 primary RC channels) will receive an update. Again, at the time of writing, no details were available, however, Simon Linden indicated there should be no user-visible changes, but the update will include fixes to lower level code that should help with scripts running and provide some better performance transferring scripts across region boundaries as well. This update has apparently been on simulators associated with the BlueSteel RC." @modemworld

 

Edited March 9, 2020 by Ample Clarity

[Pamela Galli]

Is there a JIRA link?

[Ample Clarity]

I don't know the details, that's the thing. I don't know if a sim restart will solve the problem. I seen it on 2 mainland sims: Toroge and Fearly. I don't own mainland so I can't test on other sims. I tried some of the nearby sims near Toroge and rezzed a piano on the road and it worked.

[Pamela Galli]

But the Lindens are aware?

[Ample Clarity]

I filed a ticket

[Ample Clarity]

Another customer just messaged me on the mainland sim Korzun. Same issue. This is 3 in the past 24 hours.

[Qie Niangao]

Maybe it was already known, but I TP'd around and can confirm that Taroge, Fearly, and Korzun are all running the RC release (537423) as mentioned in this week's deploy plan announcement. I hopped around a few other sims and some are running the non-RC server release (536748). I think about a third of all sims, both Mainland and Estate, are in an RC channel.

[Pamela Galli]

If you file A JIRA And post the link then we can watch it and monitor progress.

[Ample Clarity]

Thank you so much Qie! The problem is, I don't know how to describe this bug. I'm not sure what's going on.

[Lucia Nightfire]

1 hour ago, Ample Clarity said:

I'm not sure what's going on.

Contact the creator of the object and have them verify what the problem is exactly so they can file a bug report.

[Ample Clarity]

I'm the creator and have access to all the scripts full perm. But I didn't write the scripts.

[Ample Clarity]

20 minutes ago, Lucia Nightfire said:

Contact the creator of the object and have them verify what the problem is exactly so they can file a bug report.

I will find a scripter to help me debug.

[Lucia Nightfire]

1 hour ago, Ample Clarity said:

I'm the creator and have access to all the scripts full perm. But I didn't write the scripts.

Then file a jira mentioning this and offer the scipts to the Linden that responds so they can investigate it.

Edited March 9, 2020 by Lucia Nightfire

[Lucia Nightfire]

I find it odd that 2020-02-26T20:56:18.537423 exists on random regions across the grid, but not on any of the RC "A" regions...

[Logan Elf]

14 minutes ago, Lucia Nightfire said:

I find it odd that 2020-02-26T20:56:18.537423 exists on random regions across the grid, but not on any of the RC "A" regions...

I'm guessing it's part of the trying to hide the RC channel names so they all got moved to Main Channel. That way we can't know what is running on which RC channel.

However, this thread highlights to me the utter stupidity of that decision.

[Lucia Nightfire]

I did GET & POST, http-in and http-out tests between 2020-02-14T20:17:32.536748 and 2020-02-26T20:56:18.537423 using bodies containing 1,2,3 & 4 byte characters with B64,MD5 & Sha-1 match checks and haven't found anything weird yet.

Edited March 9, 2020 by Lucia Nightfire

[Ample Clarity]

it'S a bug on the server update - there is an event in scripting, it is triggered as soon as a script rezzes an object - and with the server update it seems that event is not triggered correctly anymore -  I put a message into that event right at start to see when it triggers - the message never appears

Edited March 9, 2020 by Ample Clarity
clarifying

[Ample Clarity]

https://jira.secondlife.com/browse/BUG-228285

[animats]

There have been complaints in this area recently. From the wiki:

"If an object is rezzed by another object then the object_rez event in the parent object does not trigger at the same time as the on_rez event in the child object and the order of the events is not guaranteed. See the examples in object_rez for how to reliably establish communications between objects when rezzing."

Trouble came from objects, typically guns, which rez other objects, typically projectiles, and then send a message to the projectile telling it where to go. There's no guarantee that the newly rezzed object is up and running when the gun sends the message to the projectile. But apparently that assumption used to work most of the time. Now, it doesn't. Properly, you rez the projectile, it sends a message to the gun asking "what do I do", and the gun responds "go here".

What's going on, I gather, is that there's work underway to make rezzing not impact performance so much, and that breaks an assumption made by some older scripts that rezzing has finished when the script which initiated it gets control back.

There was a discussion on this recently, but I can't find it right now.

Edited March 9, 2020 by animats

[Ample Clarity]

38 minutes ago, animats said:

"If an object is rezzed by another object then the object_rez event in the parent object does not trigger at the same time as the on_rez event in the child object and the order of the events is not guaranteed. See the examples in object_rez for how to reliably establish communications between objects when rezzing."

Trouble came from objects, typically guns, which rez other objects, typically projectiles, and then send a message to the projectile telling it where to go. There's no guarantee that the newly rezzed object is up and running when the gun sends the message to the projectile. But apparently that assumption used to work most of the time. Now, it doesn't. Properly, you rez the projectile, it sends a message to the gun asking "what do I do", and the gun responds "go here".

It's not about the order. The issue is one of the events doesn'T trigger at all.

[Lucia Nightfire]

I've had to bypass relying on_rez() and even object_rez() in some of my apps due to random failures since November 2019's "script efficicency fix".

Here's a snippet of one way to have on_rez() functionality without the presence and/or reliability of the event itself:

key my_key = NULL_KEY;
default
{
    state_entry()
    {
        my_key = llGetKey();
        llSetTimerEvent(#); //adjust however slow or fast you need to trigger the timer() event after an actual rez/attach
    }
    timer()
    {
        if ((my_key = llGetKey()) != my_key) //if object's key changes, object was rezzed/attached since last check
        {
            //check llGetStartParameter() if needed
            //stop timer or adjust polling speed if needed
            //do stuff here
        }
    }
}

Also, the random 2 second delay LL started adding to scripts on rez/attach doesn't help either, especially with some scripts in a linkset having the delay while others do not...

Edited March 9, 2020 by Lucia Nightfire

[Sayrah Parx]

I confirmed that in Toroge, Fearly and Korzun, which are on 537423, the object_rez event doesn't happen.  The on_rez event does still work as expected.  But the object_rez event definitely DOES NOT work at all.

I confirmed with the same test that on_rez and object_rez still work as expected in 536748.

But I tested in Venrigalli, Sirrakuk and Nadelhorn, which are also on 537423, and both events work.  So the bug doesn't seem to depend on 537423.  But it's definitely a problem in Toroge, Fearly and Korzun which all happen to be on 537423.

I would test in Magnum Sandbox A, LeTigre Sandbox A and BlueSteel Sandbox A but you have to be premium to enter those now.  Magnum Sandbox 1, BlueSteel Sandbox 1, LeTigre Sandbox 1, etc. also block access.  So maybe someone else can test in those.

[Ample Clarity]

37 minutes ago, Sayrah Parx said:

I confirmed that in Toroge, Fearly and Korzun, which are on 537423, the object_rez event doesn't happen.  The on_rez event does still work as expected.  But the object_rez event definitely DOES NOT work at all.

I confirmed with the same test that on_rez and object_rez still work as expected in 536748.

But I tested in Venrigalli, Sirrakuk and Nadelhorn, which are also on 537423, and both events work.  So the bug doesn't seem to depend on 537423.  But it's definitely a problem in Toroge, Fearly and Korzun which all happen to be on 537423.

I would test in Magnum Sandbox A, LeTigre Sandbox A and BlueSteel Sandbox A but you have to be premium to enter those now.  Magnum Sandbox 1, BlueSteel Sandbox 1, LeTigre Sandbox 1, etc. also block access.  So maybe someone else can test in those.

You are a lifesaver! Thank you so much Sayrah!

[Qie Niangao]

Huh. I started out testing at those "<release channel> Sandbox A" regions and they all generated object_rez() events, but then I went to Toroge, Fearly, and Korzun, and they too generated object_rez() events. I checked and those three haven't been restarted for almost 5 days (so that would be the RC channel restarts last week), so I don't know what could have fixed them. I guess we could compare rezzing scripts, but mine is trivially simple:

default
{
    state_entry()
    {
        llListen(22, "", llGetOwner(), "test");
    }
    object_rez(key id)
    {
        llOwnerSay("object_rez of "+llKey2Name(id));
    }
    listen(integer chan, string name, key id, string text)
    {
        llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos(), ZERO_VECTOR, ZERO_ROTATION, 0);
    }
}

... dropped into an object that contains some other object to rez when I type "/22 test" to chat.

[Sayrah Parx]

I noticed it looked like you were testing object_rez without testing on_rez inside the rezzed object at the same time.  So I tested object_rez with a non-scripted object and did get the object_rez event in those 3 regions.  So apparently if the rezzed object has an on_rez event then the object that rezzed it doesn't get the object_rez event in those 3 regions.