|
|
|
[
Permlink
| « Hide
]
Maggie Darwin added a comment - 30/Aug/08 06:57 AM
I bet this is connected to the legions of folks who have lost HUDs loaded with expensive no-copy animations.
Possibly related to VWR-6110 ?
Still repros for me. (Server 1.24.9)
I just got full-blown inventory loss and a crash while reproducing this with server 1.26.4.120562 and viewer 1.23.3 (122084) (the public nightly):
The object started out in the "My Inventory" root folder. After doing the above repro steps, the object then appears in the root of the inventory listing (as in, it shows up as a sibling of "Library" and "My Inventory"). Trying to drag the object out of there into some more sane folder caused SL to crash (the crash report should have been sent at approximately 11:00 AM PDT 5/30/2009). Upon relogging, the object is totally missing. just want to point out - this causes full-blown content loss - and the repro behavior is very common (wearing a no-copy object from the ground.)
also - the repro says "in quick succession" - but i tested, it happens regardless of speed. EVERY time you wear a no-copy object from the ground, it becomes detached from your inventory, and is lost. (even after relog.) Another reproducible version of this:
1. Create a new object on the ground and name it "test a" What should happen: "test a" and "test b" should both be in your objects folder and be wearable and rezable. What does happen in 1.23: Both "test a" and "test b" appear to be in your root folder. Neither "test a" nor "test b" are usuable. They cannot be worn, rezzed or moved to another folder and trying to do any of these things sometimes crashes the client. After relogging, these objects completely disappear from the inventory. Qarl, you aren't the only one working on this bug, it's also
Getting rid of the "quick succession" bit.
Updating the description...
I've got a server-side fix for this (and also a dupe VWR-6110), however it missed the deadline for inclusion in server-1.27.1. If we deploy a server-1.27.2 it will probably be in that, otherwise it would go into server-1.30. My fix doesn't address the viewer crash problem, but instead fixes the server behavior that is tickling the viewer crash bug.
This bug only affects no-modify objects, but causes no-copy objects to be "lost". Until this fix is deployed the workaround for VWR-6110 problem would be to NEVER attach from in-world - always first take to inventory, then wear from inventory. Unfortunately that does not work for llAttachToAvatar() which only functions for in-world objects. Lost inventory items are not eliminated from the database, but instead have an invalid "location" record and so don't show up in the inventory view. We have a automatic script that runs in the background and tries to find such objects and restore them to inventory, however it appears that the script runs too slowly – at least 278 days to complete! In the meantime if you've got lost inventory items just send me an IM in-world asking to have your lost items found and I'll run the script on your account. Any lost items would show up in your "Lost and Found" folder. I just tested this in 1.30.2; things have reverted back to the way they were before (i.e. a race condition).
The original repro, for reference: The following steps should be done in quick succession: 4) Attempt to rez the item from the inventory |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||