[sldev] Inventory Predicament

[Brandon Lockaby]

Inventory Predicament

It started a few months ago...  After letting the ~13,500 items of my
inventory fetch, opening the texture picker or resident picker, or opening a
second inventory window, would cause my viewer to freeze.  Everything was
fine until a certain amount of inventory fetching was done.  Also, if I
didn't clear my cache before attempting to log in again, the freeze would
happen during the login process.  So I got in the habit of hitting the
'clear cache' button every time after logging in, to make sure I didn't have
to run the viewer twice next time I wanted to log in.  And I got in the
habit of not being able to use the texture picker and resident picker.

Being a lowly Basic member, I don't have access to support, so I filed a
JIRA issue, but of course the issue was unique to me, so I eventually marked
it "more information needed" and closed it.

In connection with a viewer exploit involving inventory transfers, I had the
opportunity of a generous Linden taking a look at my inventory, and he
removed some troublesome top-level folders.  But the problems never went
away.

Several months passed :O

Tonight I had the opportunity to try the Second Inventory viewer.  It turned
out to be alot more featured than I expected.  But when I loaded my
'Objects' folder, it threw about 100 dialogs saying I had a bad reference to
"ce5da405-26d2-4004-a01c-56a3ced4d68a" or it was not a folder.

Now, I had a UUID.

In the Second Life viewer's cache folder, there's a <your agent key>.gz file
with a text file inside for caching your inventory.  I decided to search the
file for that UUID and see if I could figure out what was up.  The first
occurrence was:

    inv_category    0
    {
        cat_id    ce5da405-26d2-4004-a01c-56a3ced4d68a
        parent_id    d2ed5dee-3801-46f6-8d8a-1f01133b2673
        type    category
        pref_type    object
        name    Objects|
        owner_id    97b817dc-5dd3-498a-bdd2-5644d0aa8fb4
        version    11395
    }

That's my Objects folder.  And indeed, all of the objects inside had it as
their parent_id.  But since the Second Life viewer and Second Inventory
were, in fact, able to show all the items in my Objects folder, that didn't
make sense of anything to me.  I kept looking, and eventually found this
item:

    inv_item    0
    {
        item_id    ce5da405-26d2-4004-a01c-56a3ced4d68a
        parent_id    ce5da405-26d2-4004-a01c-56a3ced4d68a
    permissions 0
    {
        base_mask    7fffffff
        owner_mask    7fffffff
        group_mask    00000000
        everyone_mask    00000000
        next_owner_mask    00082000
        creator_id    97b817dc-5dd3-498a-bdd2-5644d0aa8fb4
        owner_id    97b817dc-5dd3-498a-bdd2-5644d0aa8fb4
        last_owner_id    00000000-0000-0000-0000-000000000000
        group_id    00000000-0000-0000-0000-000000000000
    }
        asset_id    00000000-0000-0000-0000-000000000000
        type    object
        inv_type    object
        flags    00000000
    sale_info    0
    {
        sale_type    not
        sale_price    10
    }
        name    Object|
        desc    (No Description)|
        creation_date    1195342436
    }

Amazing, it has the same UUID as the folder it's in, and must be the problem
item.  So I loaded up the Second Life viewer, fetched my inventory, and did
a search for "Object."

Unfortunately, I couldn't see the object.

So, at this point, being an overenthusiastic slproxy user, I start thinking
maybe I can figure out how to delete an inventory item by injecting a
packet, and hopefully it doesn't work by UUID alone.  I look through
http://wiki.secondlife.com/wiki/Category:Messages for messages having to do
with inventory, and log them while doing some tests with moving and deleting
inventory items.

I find I have two options:

RemoveInventoryItem
http://wiki.secondlife.com/wiki/RemoveInventoryItem
Purge a single inventory item, given its UUID.

MoveInventoryItem
http://wiki.secondlife.com/wiki/MoveInventoryItem
Move an inventory item, given its UUID, to another folder, given its UUID,
with an optional new name.

Since RemoveInventoryItem takes only a UUID, I'm too nervous to use it right
away with a UUID that represents both the problem item and my Objects
folder, even though there is a separate message, RemoveInventoryFolder, for
purging a folder.  I mean, behind-the-scenes, what if the database operation
just uses the UUID alone, and purges my Objects folder >_<  And obviously,
the UUID is enough to cause problems with the viewer.

So I use slproxy to send a MoveInventoryItem packet condemning
ce5da405-26d2-4004-a01c-56a3ced4d68a to my 'Trash' folder.

[4:04]  Analyst: failed to inject fix: Object reference not set to an
instance of an object.

I guess it won't let me inject the packet without it mentioning the NewName
parameter, and I'm not sure if using an empty string will have the desired
effect, so I add NewName = TROUBLE to the packet and inject again.

No feedback... No item visibly in my Trash...

I right-click my Trash and empty it, and verify that the viewer sent a
PurgeInventoryDescendents packet, for purging its contents.  God, I hope I
did it!

Clicked the clear cache button, logged out, logged back in, and let my
inventory fetch.  I am relieved to see I still have an Objects folder, with
objects in it.  I rez some of them while waiting for the fetching to be
over.

The fetching is over.  I create an object and click the Texture box... the
viewer stops...

But after about five seconds... IT WORKS!!  THE TEXTURE PICKER!!  How I'd
missed it ;__;  I close and open the texture picker again and again!  I use
New Window on my inventory... it takes about 15 seconds, but it worked!  I
open the parcel options and click Add next to the ban list... after six
seconds, it worked!!

Finally, I logged out without clicking 'clear cache' first, and log back
in.  Z-O-M-G, I am logged in and I already have everything fetched.  I am
hugging slproxy.

So my question is, how did this happen? :D

Can we fix the bug in the viewer that made this SUCH a problem?

And is there any danger of my Objects folder being garbage-collected, now?
;__;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080209/dab85fda/attachment.htm