https://bugs.documentfoundation.org/show_bug.cgi?id=173208
--- Comment #6 from Branislav Klocok <[email protected]> --- Second occurrence, and it removes condition (a) from the description. On 2026-08-25 the same deadlock happened while opening a 26 kB .xlsx mail attachment from Thunderbird. Same machine, LibreOffice 26.2.5.2, Qt6 VCL on Plasma 6 Wayland, Nelson MCP 0.12.1 still installed. No window ever appeared. This time, however, Recovery was not involved at all: - RecoveryList was absent from the xcu entirely, as in the first occurrence. - RecoveryInfo/Crashed=true was present, but it had been written by the hung run itself. The xcu mtime is 23:31:31, which is 1.7 s after the hung process stopped making progress. Since LibreOffice sets that flag at session start and clears it on clean exit, its presence during a run says nothing about the previous one. So Crashed=true is not a necessary condition either. What the two occurrences actually share is SynchronousDispatch on the main thread, and that is reached on any cold start of soffice with a document on the command line, which is exactly how a mail client opens an attachment. Recovery is one route into that code path, not the only one. That widens the second defect in this report considerably. It is not "Recovery holds a framework lock that blocks extension callbacks during startup", it is "the startup document dispatch holds a framework lock that blocks UNO callbacks from extension OnStartApp handlers", with Recovery being merely one way to get there. The isolation-leak defect reported alongside it is untouched by this and still stands on its own. The new backtrace captures both sides of the cycle in a single dump, which the first one did not. Main thread, holding the Solar Mutex and waiting on a framework mutex: #1 pthread_mutex_lock (libc.so.6) #12 comphelper::SynchronousDispatch::dispatch(...) (libmergedlo.so) #18 SalUserEventList::DispatchUserEvents(bool) (libmergedlo.so) #19 QtInstance::ImplYield(bool, bool) (libvclplug_qt6lo.so) #21 Application::Yield() #22 Application::Execute() #25 soffice_main() Extension Python thread, holding the framework lock and waiting on the Solar Mutex: #2 osl_acquireMutex (libuno_sal.so.3) #3 comphelper::SolarMutex::doAcquire(unsigned int) (libmergedlo.so) #5 framework::Desktop::getActiveFrame() (libmergedlo.so) #6 framework::Desktop::getCurrentFrame() (libmergedlo.so) #7 framework::Desktop::getCurrentComponent() (libmergedlo.so) #13 libpyuno.so #14 _PyObject_MakeTpCall (libpython3.13.so.1.0) Five threads in total were queued on SolarMutex::doAcquire. Full dump of all 14 threads attached. There is one observation I cannot explain and which may mean more to someone who knows the startup sequence. The hung process had cert9.db and key4.db from the Thunderbird profile open, so NSS had been initialised from the Mozilla profile during startup. None of my healthy runs opened any NSS database at all. Since Thunderbird exports LD_LIBRARY_PATH=/usr/lib64/thunderbird and MOZILLA_FIVE_HOME, a soffice started from it also links against Thunderbird's NSS rather than the system one. Whether that is part of the lock chain or an unrelated side effect, I do not know, but it is the only difference I found between the hung run and the healthy ones. I should be clear about what I failed to establish. The user hit this twice in a row on the same message, but I could not turn it into a reproducer. Nine deliberate cold-start attempts all succeeded, with the window up and the main thread in poll_schedule_timeout: three runs of soffice <file> from a terminal, three of soffice --calc <file:// URI> byte-identical to the failing command line, and three more with the environment copied verbatim from /proc/<thunderbird pid>/environ. The race window is evidently narrow, and I have not found what widens it. A workaround that does hold: let an empty Start Center come up first and pass the document to the already running instance. The extension finishes its bootstrap before any document dispatch and SynchronousDispatch never enters the picture. Attachments open normally as long as LibreOffice is already running; only the cold start is exposed. Also worth correcting for anyone tracing this: the line "get_active_document: getCurrentComponent() returned None" in the extension's log is not a signature of the deadlock. The extension writes it on every startup, successful ones included. I initially read it as one and that was wrong. -- You are receiving this mail because: You are the assignee for the bug.
