Right clicking the root "My Inventory" folder freezes the viewer with no recovery

[canny]

• This might need a large inventory or an inventory with many items in the root folder to reproduce

• Login and open inventory

• In the "My Inventory" tab, right click the root "My Inventory" folder.

• Observe the viewer freezes & never recovers, needing a force quit in Task Manager

• The freeze also reproduces when right clicking the "My Inventory" folder in the Recent tab of inventory if inventory folders are set to show items newer then 100 days. The number of days is unlikely to be important, it's probably the number of items showing in the root folder that matter.

• I attached my log from a session where I reproduced this - observe in the log that right clicking the root inventory folder appears to cause a cache purge & it might be the cache purge that is causing the viewer to freeze?

• You can see the last log lines are

2025-02-03T19:23:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

2025-02-03T19:24:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

2025-02-03T19:25:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

2025-02-03T19:26:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

2025-02-03T19:27:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

2025-02-03T19:28:59Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

2025-02-03T19:29:59Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

2025-02-03T19:30:59Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes

	

• Feel free to hijack Whirly Fizzle if you can't reproduce this.

• Freeze also reproduces on ForeverFPS & Firestorm

https://secondlife.canny.io/admin/board/bug-reports/p/right-clicking-the-root-my-inventory-folder-freezes-the-viewer-with-no-recovery

[canny]

This issue has been linked to a Canny post: Right clicking the root "My Inventory" folder freezes the viewer with no recovery 🎉

[AtlasLinden]

Related bug that was fixed in Maint X: secondlife/jira-archive#11537
Reproduces 100% of the time with Whirly's account

[Dan-Linden]

I tested on Whirly's account. It did not repro on the first login. It did repro on the second login, when the inventory was fetched from cache.

[kylelinden]

@Dan-Linden @AtlasLinden Does this freeze show up in bugsplat?

[akleshchev]

I don't think there will be any freezes in bugsplat.

In discussion with bugplat it came up that bugsplat is supposed to catch freezes (setHangDetectionTimeout()) but it doesn't appear to catch our 'infinite loop' case. Bugsplat monitors Windows' message loop, which keeps working. We probably should make our own detection.

[akleshchev]

checkFolderForContentsOfType is expensive and frequently used, will need to rewrite it to quit on first found item instead of collecting every item. Also need to make buildContextMenuOptions avoid some checks for 'my inventory'.

[akleshchev]

I fixed most expensive elements, but a small, couple frames long freeze remains. Part of the cause for the freeze is a large update from simulator for the root folder, fixing response provessing in scope of forever FPS is too risky (and probably involves threading inventory), so if you see a small freeze, please file a separate ticket. For this ticket it's enough that viewer 'recovers'.

Test plan:

1. Confirm viewer does freeze permanently
2. Confirm IM options work correctly for folders that contain colling cards
3. Confirm options to wear wearable containing folders work correctly
4. Check fetching speed. This fix is UI specifc and should not affect fetching, but whirly reported issues so needs testing.

[Whirly-Fizzle]

@akleshchev

Testing on build https://github.com/secondlife/viewer/releases/tag/Second_Life_Release%231924241f-ForeverFPS

The unrecoverable freeze is fixed \o/

However,
After right clicking on the root inventory folder, the inventory goes into a "fetching" state, even though it is full fetched, and when the mouse cursor is inside the inventory window, the cursor changes to the egg timer.
While the inventory is in this fetching state, sending an IM via a calling card is working correctly & I am able to add & remove wearables (shape, tattoos etc).
Other inventory operations liker moving item,s between folders seem to be working fine too - there were no signs of inventory selection jumping around.
It takes ~7 minutes for the inventory to stop being in the fetching state & the cursor inside inventory to return to normal.

I don't think the inventory being stuck in the fetching state for several minutes is a big issue.

[Whirly-Fizzle]

@akleshchev

I found a minor bug that only appears to reproduce on the test build
The bug just seems to be excessive log spam, so very minor.

• Login on the above build

• In inventory open Calling cards -> Friends -> All.

• Check the secondlife.log to verify there is no log spam

• Right OR left click any calling card in the All folder.

• Observe that the log file is spammed with hundreds of lines of WARNING # newview/llappearancemgr.cpp(2075) LLAppearanceMgr::canAddWearables : Unexpected wearable type

• Example of the log spam: https://prnt.sc/Zgf7MkfNGGLT

• The log spam doesn't stop until you deselect the calling card

• On default release Second Life Release 7.1.11.12363455226, the log spam does not reproduce. You only get a single line of "WARNING # newview/llappearancemgr.cpp(2075) LLAppearanceMgr::canAddWearables : Unexpected wearable type" when the calling card remains selected.

[akleshchev]

It takes ~7 minutes for the inventory to stop being in the fetching state & the cursor inside inventory to return to normal.

That matches what I see and was the cause behind the freeze. When you right click root folder viewer checks if it's up to date. If it isn't up to date viewer tries to fetch that folder. That response for some reason contains over 3K folders. It's processing those 3K folders, each individual folder updating open menu. That update is expensive, so viewer effectively froze. I focused on fixing the freeze.

P.S. Viewer probably can handle that response in secodns, but really need threadng for inventory before that.

The log spam doesn't stop until you deselect the calling card

Thank you, will check that.

Edit: Can not reproduce. if fetch is still ongoing, each received item is going to refresh open menu which is expected (I can make a filter to only update menu if viewer got an update for a related item, but it's a minor issue)