Conversation
|
All contributors have signed the CLA ✍️ ✅ |
…ename When an in-world object is destroyed (via llDie, temp expiration, or deletion) while an item inside its Contents tab is being renamed, the viewer crashes with an Access Violation (0xC0000005) during LLMortician teardown. Root Cause: - LLPanelObjectInventory::clearContents() queued mScroller for deletion and nulled mFolders without canceling the active renamer or releasing keyboard focus. - During destruction, LLFolderView::~LLFolderView() cleared mViewModel to NULL. - When base view destructors released focus from mRenamer (LLLineEditor), commit_on_focus_lost triggered onCommit() -> commitRename() -> arrange(). - arrange() attempted to call getFolderViewModel()->sort(this) while mViewModel was NULL, resulting in an immediate NULL-pointer dereference on a half-dead view. - LLEditMenuHandler::gEditMenuHandler was also left pointing to the destroyed mFolders. Fixes: - Added LLFolderView::cancelRenaming() to disconnect callbacks, disable commit-on-focus-lost, remove the popup, and release focus via gFocusMgr. - Called cancelRenaming() in LLFolderView::~LLFolderView() and deleteAllChildren(). - Added defensive null checks for mViewModel in finishRenamingItem() and commitRename(). - In LLPanelObjectInventory (clearContents, deleteAllChildren, ~LLPanelObjectInventory), cancel renaming on mFolders and clear gEditMenuHandler before mFolders is nulled. - In LLFolderViewItem::destroyView() and LLFolderViewFolder::extractItem(), cancel active renaming if the item being destroyed/extracted is currently being renamed.
soapyf
force-pushed
the
fix/task-inventory-rename-crash
branch
from
September 15, 2026 00:59
0f999d4 to
279f3fb
Compare
Author
|
I have read the CLA Document and I hereby sign the CLA |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes a Crash-to-Desktop (Access Violation
0xC0000005) that occurs when an in-world object is destroyed (viallDie(), temporary expiration, or deletion) while a user is actively renaming an item inside its task inventory (Contents tab).Context & Root Cause
When the containing object is destroyed,
LLPanelObjectInventory::clearContents()queues the view for deletion and nullsmFolders, but leaves keyboard focus on the active inline text editor (mRenamer). During deferred destruction inLLMortician,LLFolderView::~LLFolderView()clearsmViewModel = NULL. Subsequent base class destructors then release keyboard focus frommRenamer, which triggerscommitRename()->arrange()->getFolderViewModel()->sort(). BecausemViewModelwas already cleared, this causes an immediate null-pointer dereference on a half-destructed view.Changes
LLFolderView::cancelRenaming(): Disablescommit_on_focus_lost, disconnects top-lost signals, removes the popup fromLLUI, and cleanly releases keyboard focus viagFocusMgr.cancelRenaming()in~LLFolderView(),deleteAllChildren(), andLLPanelObjectInventory::clearContents().LLEditMenuHandler::gEditMenuHandlerbeforemFoldersis nulled inLLPanelObjectInventory.mViewModelinfinishRenamingItem()andcommitRename()to ensurearrange()is never invoked against a dead view model.Related Issues
Issue Link: Closes #6320
Checklist
Please ensure the following before requesting review:
Additional Notes
llDie()while renaming an inventory item inside its Contents tab, and confirming that with this fix applied the rename aborts cleanly with no crash or UI lockup.