https://bugs.documentfoundation.org/show_bug.cgi?id=174044
Bashar Al Halabi <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|1 |0 Status|NEEDINFO |UNCONFIRMED --- Comment #2 from Bashar Al Halabi <[email protected]> --- The use case is the same as in bug 174043: an Android app that embeds LibreOfficeKit through its C API. I agree the Writer-only Android build is a poor reproducer; it is only where I first ran into this. The crash depends on neither Android nor that setup, and it reproduces with the official macOS build: 1. Copy the app from the official LibreOffice_26.8.1_MacOS_aarch64.dmg (26.8.1.1, unmodified) to a scratch folder. 2. Truncate one installed file, as an interrupted copy or update would leave it: head -c 4096 services.rdb.orig > LibreOffice.app/Contents/Resources/services/services.rdb 3. From a minimal client, call lok_init_2("<copy>/LibreOffice.app/Contents/Frameworks", "file:///tmp/lokprofile"). Result: Bootstrapping exception 'unterminated attribute value in file:///<copy>/LibreOffice.app/Contents/Frameworks/../Resources/services/services.rdb' then EXC_BAD_ACCESS (address 0x8): SalInstance::GetYieldMutex() lo_destroy(LibreOfficeKitStruct*) libreofficekit_hook_2 lok_init_2 With the intact copy, lok_init_2() succeeds. So any failure that lo_initialize() catches before VCL is up turns into a crash instead of a NULL return: libreofficekit_hook_2() calls lo_destroy() (init.cxx line 8446 at 26.8.1.1), which first takes the SolarMutex (line 8476), and in a normal start VCL only comes up later, on the lo_startmain thread. The Viewer relies on that NULL as well: sal/android/libreofficekit-jni.c (initializeNative) logs "libreofficekit_hook returned null" and returns JNI_FALSE, a branch such a failure never reaches. Expected: lok_init_2() returns NULL, so the caller can report the bootstrap error. -- You are receiving this mail because: You are the assignee for the bug.
