Jump to content

Deploys for the week of 2011-09-12


Oskar Linden
 Share

You are about to reply to a thread that has been inactive for 4575 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

This week we are promoting the code that was in the LeTigre RC channel.


Second Life Server (main channel)
This is a "maint-server" project that has some crashing fixes and bug fixes.
Fix for SVC-7169 - "Folders are Texture Category Folders"
Fix for SVC-7192 - "llSetMemoryLimit - Wrong amount being reserved for memory/Display inconsistance with OBJECT_SCRIPT_MEMORY"
Fix for SCR-162 - "Bounds error when calling PRIM_LINK_TARGET in a child prim"

 

2011-09-13, 5:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/11
 

Second Life RC BlueSteel
This channel is getting some mesh fixes. Changes were made to prim accounting and parcel prim behaviour. 

2011-09-14, 8:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/11
 

Second Life RC LeTigre
This channel is a maint-server branch that has a lot of bug fixes. llCastRay is enabled!

2011-09-14, 9:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/11
 

Second Life RC Magnum
The code in this branch did not pass merge and will not be released this week. This channel will be set to match trunk.

2011-09-14, 10:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/11
 

We will be monitoring this thread during the next week so please feel free to post issues that you feel have been introduced by the new code. Please file a JIRA for issues you find and post the JIRA link into this thread. It really helps us out. When determining if issues are relevant or not research is key. Tracking down exactly the right situation where an issue is occurring greatly speeds up the development process to get fixes in place.
I appreciate your help. Have a good week!
 
__Oskar
 
p.s. If you are interested in helping test SecondLife in beta please join the group "Second Life Beta" in-world. We also have an email list where we communicate upcoming projects and how you can help. ( https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta ) Once a week we meet on ADITI to discuss new features, new bugs, new fixes, and other fun stuff. You are more than welcome. Information is here: https://wiki.secondlife.com/wiki/Server_Beta_User_Group
Link to comment
Share on other sites

@Jack

Maybe this is the reason?  I would guess there wasn't any testing.

"Changes were made to the permissions system and to simulator configuration, but should have no impact on existing builds

This from the heading post in the release notes.

Link to comment
Share on other sites

Wouldn't be nice if instead of piling on new enhancements, LL spent a month or two actually trying to fix the database and lag problems that have been plauging us since these restarts began.  At present this service is totally unreasonable with lag in virtually every operation including chat and inventory, massive transaction failures and apparenetly log in trouble as well.  What we need now is no mesh and a new viewer but basic services and it appear that Linden Labs is either unable or unwilling to provide that.  The solution is simple they can fix it or watch their core player base vanish. I hope someone with some degree of responsibility listens to this plea for help from the playing population but given the past history of Linden Labs, I rather douby it will even be notice.

Link to comment
Share on other sites

We have traced the cause of SVC-7283 to a security fix around permissions.  Due to the urgency of the security issue, we deployed the fix to all channels of the grid at once.  Unfortunately, we cannot 'roll back' the change at this point, since doing so would compromise permissions across the grid.  We are working on a fix for SVC-7283 - we hope to deploy the fix to an RC channel next week.  We apologize for the inconvenience and problems with update scripts which are caused by this bug.

 

__Oskar

Link to comment
Share on other sites

@ Oskar, and more importantly @ Linden Lab

SVC-7283 is surely showing that your release procedure, which I thought would prevent this sort of catastropohe occurring is still very much inadequate.  You have many scripted-item creators begging you to roll-back before too much lasting damage occurs.  This is uncomfortably reminiscent of last Sunmmer's Server 1.40 debacle, but there is something under the surface of this issue which I find most disquieting.  In a post on said JIRA Chorazin Allen makes a very interesting point:

"Why am I asking this? Stop and think about this security fix for a moment. Breaking this behaviour is not the result of a programmer putting a decimal point in the wrong place or some similar accident. Breaking it was intended - two diferent script functions were changed, error messages were added - in short, I think the security fix 'functions as designed'. Similarly, I presume that it passed QA and functioned as designed there too.

The problem is that the design of the fix either failed to consider the genuine use cases here, or was purposely designed to block them based on some exploit very close to, but different from, the genuine use cases.

Which is it? Will the ability to give objects and scripts to worn items be restored or is it gone for good in its present form?"

This gives me a most uncomfortable feeling that there is method in this apparent madness, and may also go some way to explain the apparent lassitude in LL's "fix programme"

I think there is some "owning up" to be done by Linden Lab here.  At the least it shows beyond any remaining doubt in my mind, that a huge proportion of Linden Lab programmers have NO IDEA how Second Life actually functions.  That there is far too little "InWorld" activity by said Linden employees, and the upshot is that they had no conception of what effect the changes they were introducing would actually have.

If this is the case, and I'm bound to say I think that it IS, then Linden Lab have lost any credibility with a substantial portion of its customers. 

That is the road to Hell and failure, Linden Lab.

        
Link to comment
Share on other sites

rolling back security fixes to permissions that contain bugs that can be worked around for most users is a silly request. especially in light of the fact that as soon as they became aware of the bug (which can be worked around) they went immediately to work on a fix for it.

I sympathize with the people with RLV specific items that are stuck not being able to update certain items until it's fixed, but LL is under no obligation to support RLV....

 

and while their test plan did miss the specific case, it's not surprising since the test plan makers probably did not expect there to be a difference between the permission while rezzed, and attached (especially since there are auto grant permissions for attachment).... yes it needs to be added to the permission test plan, but it hardly describes "very much inadequate"

Link to comment
Share on other sites

@Void

You are missing the point again, Void.  I agree, if RLV users were the only folk suffering from this bug, your point would be valid (though I doubt that Amethyst Rosencranz, Mars Tamale and several others would agree).

There are many HUDs that cannot be rezzed to be updated, and over and above that there are other script-related permissions issues that are badly affected.

The fact is that the test plan does seriously miss some massively important aspects of SL.  It demonstrates that the programmers do not understand how SL works "live".  That, to me, is very much inadequate.

An understanding of  "How SL is Used" by programmers is becoming necessary (actually it always has been), and it merely goes to show that with a few notable exceptions, most of the LL programmers have a totally inadequte experience of SL,  due to the high turnover of staff at the Lab.

 

Link to comment
Share on other sites

the only instance of a (non RLV) hud that cannot be rezzed is one that self destructs when you do so.

I have zero sympathy for any creator who does that, and recommend user avoid their products like the plague that they are

 

and like I said, I sympathize with some of the specific RLV affected (not all are), LL isn't obligated to support extensions (or limitations) outside of their provided service... they do generally try to accomate when they can though. That doesn't mean those users are unimportant, but core concerns always come first.

 

I agree that the test plan had a hole and needs to be updated, and as you pointed out, that might have been where the exploit lay. but fixing exploits is of primary importance,and it would be insane to rollback protective patches over an issue that has a work around for the majority of affected users. Time is much more effectively spent leaving the security fix in place letting most users take advantage of the work around, and working to restore the minor loss in functionality for both the users relegated to the workaround, and those unable to take advantage of it.

the worst effect for users that cannot access the workaround (or are unwilling for whatever reasons) is that they have to wait a week or so to update....

and just to note, I'm highly aware that a few people that used kill script upgrade cycles (where the object stops working if an upgrade is found) got caught out on this...  however all of those can be converted in place to send replacements rather than updaters, and hopefully should serve as a lesson that paticular channel of logic is more susptible to interference.

my point is, and stands at: acceptable security is a higher priority than limited use cases, especially when simple workarounds take care of the majority of those cases untill full service can be restored (where possible, if taken as a general statement since some security fixes do permanently disable some features... just not this one)

Link to comment
Share on other sites

@Void.

This bug has nothing to do with RLV or with huds that self-destruct when being rezzed. This bug effects all users that try to update their attachemts or huds while they are still wearing them and it also effect devices that are designed to transfer scripts and other inventory items between prims during normal operation.

Many content creators created easy to use updaters that allow you to update theit products while being worn. Normally this kind of updater is very safe to use. No need to rez  a no-copy item, no items getting unfindable after they are rezzed under some surface, no objects getting no-Mod in inventory just because they were rezzed and taken back again, etc.

The effect of this bug is that such an updater does not work anymore. Even worse, the object being updated is destroyed by this bug.

The workaround is not workable. Most updaters are (for good reasons) located in no-rez area's where ppl can not rez the huds or attachments.The real problem is that you can not force your customers to rez their items before updating them. You can add a warning, but i am sure many ppl won't notice it. Living without updaters for two weeks is bad, but i could live with that. Updaters that destroy products that are being updated are as bad as the security bug that was fixed by this roll. In my opinion this bug that uncontrollable destroys content should be handled with the same priority as the security bug. It is unacceptable to keep this bug on the grid for two weeks.

 

Chriss

Link to comment
Share on other sites


Chriss Rosca wrote:

@Void.

This bug has nothing to do with RLV or with huds that self-destruct when being rezzed. This bug effects all users that try to update their attachemts or huds while they are still wearing them and it also effect devices that are designed to transfer scripts and other inventory items between prims during normal operation.

Many content creators created easy to use updaters that allow you to update theit products while being worn. Normally this kind of updater is very safe to use. No need to rez  a no-copy item, no items getting unfindable after they are rezzed under some surface, no objects getting no-Mod in inventory just because they were rezzed and taken back again, etc.

The effect of this bug is that such an updater does not work anymore. Even worse, the object being updated is destroyed by this bug.

The workaround is not workable. Most updaters are (for good reasons) located in no-rez area's where ppl can not rez the huds or attachments.The real problem is that you can not force your customers to rez their items before updating them. You can add a warning, but i am sure many ppl won't notice it. Living without updaters for two weeks is bad, but i could live with that. Updaters that destroy products that are being updated are as bad as the security bug that was fixed by this roll. In my opinion this bug that uncontrollable destroys content should be handled with the same priority as the security bug. It is unacceptable to keep this bug on the grid for two weeks.

 

Chriss

Exactly all of the above.  Many of my products are components that can be installed into certain other products, plug-ins.  These aren't updates that i'm sending out, they're add ons.  As a result, customers have these already, they've had them for months, years and the process that is documented in up to 8 languages is "no need to detach your item, just rez the plug-in and Update button".

This information is no longer valid, I cannot provide a message to a product that has already been sold and is in someones inventory and has been for a couple of years that is still a current component of the system.

I have sent messages to group members, that's about all I can do.  I'm now answering the same IM's over and over "why does my <item> fail to update and give this message?"

Users, customers, call them what you wish, don't expect to have to follow the nuances of LL's poor QA and nor should they, however this issue has massively increased support for merchants and while saying "well the workaround is just to rez the objects", yes that's fine, AFTER you've replied to yet another IM which has been caused by LL's failure to adequately QA, or subsequently fix, OR seems to care about fixing in any sense of haste.

As a responsible merchant, myself and my support staff will do what we have to.

As a responsible software platform provider, it's about time that LL acted like one that had mature QA and change control processes and didn't keep putting itself on a worldwide stage, making immature errors in front of peers and superiors that do this properly on a daily basis.

This is the second time in very few months where LL has hugely negatively impacted people and it's the second time that it appears to have a "yeah whatever, we'll fix it next week" attitude, just like the last one (homestead performance issues).  If that attitude is false, please provide clear documented evidence to suggest otherwise, we don't see it yet.

Link to comment
Share on other sites


Chriss Rosca wrote:

[...] The effect of this bug is that such an updater does not work anymore. Even worse, the object being updated is destroyed by this bug. [...]

not permanently, but potentially in the short term.

worst case scenario is that the script to be replace was the one that initializes transfer, but if that's the case transfer isn't unintialized, and a "fixit" updater can continue where the other left off.

as for the rest of you comments I addressed that above. 1-2 weeks if unable or unwilling (for whatever reasons).

Link to comment
Share on other sites


Void Singer wrote:

[...] not permanently, but potentially in the short term. [...]


Most updaters check for the presence of scripts before they send the update. Creators don't like to update empty boxes to full functional products. Of coarse there will be smarter updaters and updaters that are less restrictive, but you can not state in general that the damage is only short term. A lot of products will be permanently destroyed and ppl will have to beg the creators for a free repair.

Chriss

Link to comment
Share on other sites

I'm not going to guess at what "most" updaters do, but I know my designs for secure updaters never do that, because they're integral. but that's a design issue that I'll agree certain updaters have (including some by a rather well-known person who knows better but has insisted on relying on other methods even when simpler and better were given freely)

Link to comment
Share on other sites

 

Void Singer wrote:

the only instance of a (non RLV) hud that cannot be rezzed is one that self destructs when you do so.

I have zero sympathy for any creator who does that, and recommend user avoid their products like the plague that they are

While ours can be rezzed, Void, it won't work.  It needs to handshake with another worn object, and it is all but impossible to manipulate the controls (try hitting a 0.015m cube that's invisible on five sides and partially transparent on the sixth, embedded with 102 other prims never intended to be seen any way other than end-on).  If rezzed on the ground, it basically says "don't do that" and shuts down until taken back into inventory and worn.  And inventory transfer is part, not of its updating, but of its normal functioning.

Not to say I don't think a SEC fix shouldn't take priority.  Just to point out you haven't thought of all use cases.

Link to comment
Share on other sites

you're right of course, bad call on my part there (although drag select does mitigate targeting issues, but it a very legit reason not to want to, but the rest certainly stands).

 

and don't get me wrong, I'm not saying that it isn't a bad problem, and needs both fixed and ...

ANNOUNCED SO THAT CONTENT CREATORS AND USERS CAN MITIGATE THE PROBLEM, (aimed at LL in general)

... but like you, I'm still in favor of the SEC fix taking precedence

Link to comment
Share on other sites

@Linden Lab and indirectly @Void Singer

So far, despite Maestro's efforts, the Lab has not been able to design a fix for this bug.  The tests last night on Aditi appear to have failed (see SVC-7238).

There are so many cases where the user cannot use the workaround that it is not worthy of the name.  There are also items, though thankfully I do not have any, where merely using the item causes it to break permanently.  For that latter information I have to rely on the word of others, so I cannot place any solid proof on this blog.

Tonya Souther mentions in the JIRA the Server 1.40.0 - 1.40.2 debacle of last summer, and there are a couple of other SNAFUs since then, but this simply bears out my assertion that LL's testing regime regularly and seriously falls down.

That there is work going on to fix this bug is good, but time and again we are told that the faulty code "cannot be rolled back due to security issues", yet of course we are not told what those security issues are ("to detail this fix would be to provide a potential route to avoidance by miscreants").

So, we must take it on trust that our best interests are being served by Linden Lab.  Sorry, I do not accept or believe that.

 

Link to comment
Share on other sites

the 1.4 problems with mass content breakage was actually due to poor programming on the USER side (with many on the side of letting the bad stuff stay broken)... LL did roll it back in short order though.

but because of it we got the current system which has actually worked quite well to prevent major problems while still delivering patches and upgrades in a timely fashion.... the only major event (not including this one) was the mono2 patches which were caught and rolled back quickly.

unfortunately security fixes are out of band to the current process, as they must be, and can't reasonably be rolled back. if you want to figure out what the security patch was, it's fairly easy, as at least one leg of the problem is listed in the current issue's jira comments.... if you've had to deal with spotting content theft, the rest should become very clear even without knowing the exact method involved.

 

none of that mitigates LL's responsibility to inform users when normal and expected actions can cause losses. The Grapevine method of users playing Coconut Telegraph to spread the word is not feasible. Content problems/loss that could easily be prevented will continue to happen until users just happen to hear about it, or a fix is in place; that is not acceptable business practice.

Link to comment
Share on other sites

We have a product that deliberately stops when rezzed, it can only function when worn.

It receives plug-in components via llRemoteLoadScriptPin. 

Nobody can update their product.

What's the overall plan on fixing this monumental break across the whole grid please?  There's a couple of us in this thread and on the JIRA would like to know a little more than "we'll look to try an update on ONE of the RC candidates".

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4575 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...