https://bugs.documentfoundation.org/show_bug.cgi?id=170805
Michael Weghorn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression By| |Michael Weghorn Assignee|[email protected] |[email protected] |desktop.org | Status|NEW |ASSIGNED Keywords| |bibisected, bisected, | |regression --- Comment #4 from Michael Weghorn <[email protected]> --- (In reply to Mike Kaganski from comment #3) > Most likely regression after 3c20c8ed01bde299d3e40186edcd3a6021baeee3 - hard > to tell because bisect repos lack automatic update check. > > No, it's not "always non-null": it is destroyed in the call to > myExtMgr->Close() in ServiceImpl::startExecuteModal, and the thread happily > tries to dereference the destroyed object. Thanks for the analysis. I don't see any issue with 3c20c8ed01bde299d3e40186edcd3a6021baeee3 itself. `Thread::m_pDialogHelper` was technically "always non-null" as it was never set to null before the above commit. (It was non-null, but a dangling pointer after the object was destroyed before the above commit, i.e. the problem was effectively the same as the reference to the deleted object with the commit in place.) This is a regression from another commit part of some extension manager refactoring, however: commit 5a6985c124c7a0ca246fbc920ab5e024d72a5e4a Author: Michael Weghorn Date: Sat Nov 8 09:42:17 2025 +0100 tdf#169318 extension mgr: Deduplicate close logic Pending fix: https://gerrit.libreoffice.org/c/core/+/200151 -- You are receiving this mail because: You are the assignee for the bug.
