https://bugs.documentfoundation.org/show_bug.cgi?id=172229
--- Comment #5 from [email protected] --- Created attachment 207208 --> https://bugs.documentfoundation.org/attachment.cgi?id=207208&action=edit Minimal reproduction extension for bug 172229 Hello!! Minimal reproduction extension is attached as bug172229-repro.oxt, with a README covering installation, reproduction steps, and design notes. The OXT exposes a small HTTP server (port 8766) with three independent endpoints, each demonstrating one failure mode from the original report: • POST /save_existing — doc.store() on a previously-saved active document • POST /save_as — doc.storeAsURL("file:///tmp/...", ()) on any active document (also the code path LO invokes internally when an Untitled doc is saved for the first time) • POST /create — loadComponentFromURL("private:factory/swriter", "_blank", 0, ()) All three reproduce the hang deterministically on the affected configuration (macOS Tahoe 26.5 / LibreOffice 26.2.3.2 / Apple Silicon M1). To restate the regression timing from the original report, since it bears on root cause analysis: the same extension architecture worked correctly on earlier Tahoe releases (26.0–26.4) paired with LibreOffice 26.2.x. The hang began appearing in mid-May 2026, around the time both macOS Tahoe 26.5 and LibreOffice 26.2.3.2 (released May 19) landed on this machine within roughly a day or two of each other. The 26.2.3.2 release is the .2 point release of 26.2.3 (April 30 release); I can't confirm whether 26.2.3 base was running cleanly here before 26.2.3.2 installed, so the regression window on the LO side could be either "26.2.3.2 specifically" or "somewhere in 26.2.3.x." Because both the Tahoe and LO updates landed in close proximity, I can't yet say which one is the proximate cause — only that the combination produces the failure on this hardware. A test on an Apple Silicon machine that took only one of the two updates would be the cleanest way to isolate which side regressed, if anyone reading the bug happens to have access to such a setup. A 1–2 second pause precedes the spinning beachball in each case, suggesting the call partially executes before deadlocking rather than failing immediately at entry. The /create endpoint from the Start Center additionally produces a visible empty black window frame mid-creation, which may be a useful visual marker for someone debugging the renderer/frame layer. The extension itself is ~250 lines of Python in a single file plus the OXT scaffolding (manifest, Addons.xcu, description.xml). It uses the same JobExecutor-based menu wiring as the original mcp-libre architecture but with no async machinery, no queue, no AsyncCallback registration, no DispatchHelper — just an HTTPServer on a daemon thread making one direct UNO call per endpoint. This minimal repro hasn't been tested on Windows or Linux. The OXT manifest specifies platform="all", so the extension should install on those platforms, but the reproduction behavior is unknown. The same extension architecture (the upstream mcp-libre project this minimal repro is derived from) ran without the hang on Windows 10 Pro under earlier LibreOffice 26.2.x point releases before the mid-May LO update, but I haven't been able to retest on Windows since LO 26.2.3.2 landed because that machine has been down for an unrelated hardware issue. So I can't confirm whether the bug reproduces on the current Windows + LO 26.2.3.2 combination. A test from anyone with that setup running would be very helpful for isolating whether this is macOS-specific or affects LO 26.2.3.2 more broadly. One platform-specific UI note for anyone testing the repro cross-platform: based on prior experience with similar extension architectures, the Bug 172229 Repro menu integration on Windows only appears in the menu bar after a document is open (any kind — a fresh Untitled Writer doc is enough), whereas on macOS the menu is also visible directly from the Start Center with no document open. The first time switching between platforms this difference can be a little surprising. This applies to the menu visibility for starting the server, not to whether the bug itself reproduces. I've also been digging on the side trying to find at least a temporary workaround so I can keep using this for my daily work while the underlying issue is sorted out. Two related findings from that effort which may be relevant to the broader Tahoe + LO integration picture: Attempts to bridge LO via the standard external-Python UNO socket (--accept=socket,host=localhost,port=2002;urp;) also fail on this configuration. Running LO's bundled Python (/Applications/LibreOffice.app/Contents/Resources/python) directly from Terminal is killed by macOS with EXC_CRASH (SIGKILL (Code Signature Invalid)) / Namespace CODESIGNING, Code 4, Launch Constraint Violation before any user code runs. Homebrew Python 3.12.13 (matching LO's bundled version exactly) with PYTHONPATH set to find LO's UNO modules instead segfaults inside pyuno.so during import — likely due to two libpython3.12.dylib instances ending up in the same process. So while these are separate symptoms from the in-process OXT hang, they suggest the Tahoe 26.5 / LO 26.2 combination has closed off both the in-process and the external-process paths that previously worked. I should add that I'm not a developer by background — I keep digging on this because the workflow it enables has become genuinely useful to me and I'd like to see it working again, but the deeper technical layers are at the edge of what I can untangle on my own. Happy to provide additional context, the full segfault crash report, or session notes from the debugging process if any would help. Thanks again for any help with this!! -- You are receiving this mail because: You are the assignee for the bug.
