[sldev] Inventory Predicament

Timeless Prototype timelessprototype at gmail.com
Sat Feb 9 05:48:50 PST 2008


Tateru, you're my official life saver! Forever in your debt.

I moved all my chat logs (~32MB) to an archive folder, logged on and 
re-enabled all chat log options. I can now function without the screen 
freezes in Windlight viewer (don't really care about the other viewers).

Thank you. Thank you. Thank you. XD

- Timeless

Tateru Nino wrote:
>
>
> Timeless Prototype wrote:
>> Wow, very cool.
>>
>> My Timeless Prototype avatar is no longer usable, I have missing 
>> assets and whenever a friend comes online (regardless of notify 
>> option) it locks up the SL viewer for about 5 seconds (ie. absolutely 
>> nothing moves on the screen, not even the mouse). With the number of 
>> friends I have it's impossible to do anything with this fault. All 
>> other applications are fine, even SL voice continues happily whilst 
>> this happens.
> Just wondering - do you have chat-logging enabled, and where're the 
> log files going to? I had a problem with lockups when friends went 
> online/offline and when certain people sent me an IM. Turned out that 
> in the wake of a power-flutter at some point, the chat/IM log files 
> had been left in a locked state.
>
> I've also seen degenerate behavior when the system is trying to log to 
> an inaccessible path.
>>
>> I too am on a basic account with no phone support. I've managed to 
>> log on and do some very basic maintenance, even though extremely 
>> painful, but I'm afraid it's the end of SL for me unless this can get 
>> fixed. The problem only started with the latest Windlight and RC 
>> viewers. The "stable" viewer has other issues for me, such as the 
>> huge delay whilst logging on, resulting in a nice faceplant and 
>> failure to load my avatar. My alts log on just fine, no issues 
>> whatsoever with those.
>>
>> I refuse to buy a sim just so I can report a fault with my one 
>> avatar's inventory via phone. Just like you, Jira has proved 
>> absolutely useless to me for reporting a bug that relates only to my 
>> situation.
>>
>> - Timeless
>>
>> Brandon Lockaby wrote:
>>> 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? ;__;
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html
>>>   
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>



More information about the SLDev mailing list