Hi, this shouldn't happen and is a bit artificial, but it actually happened, see below. Try the following in a LO install. $ rm -rf share/extensions $ touch share/extensions This results in a 0 byte file. This results in a crash: Thread 1 (Thread 0x7f6e40cb9180 (LWP 689175) "soffice.bin"): #0 0x00007f6e472fda3f in __GI___poll (fds=0x7ffc488cce78, nfds=1, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f6e3e330180 in ?? () from /lib/x86_64-linux-gnu/libKF5Crash.so.5 #2 0x00007f6e3e330b87 in KCrash::defaultCrashHandler(int) () from /lib/x86_64-linux-gnu/libKF5Crash.so.5 #3 0x00007f6e4b94e8d4 in ?? () from /usr/lib/libreoffice/program/libuno_sal.so.3 #4 <signal handler called> #5 0x00007f6e452796a5 in ?? () from /usr/lib/libreoffice/program/libuno_cppu.so.3 #6 0x00007f6e45277ae8 in ?? () from /usr/lib/libreoffice/program/libuno_cppu.so.3 #7 0x00007f6e49e735c8 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so #8 0x00007f6e49e798a5 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so #9 0x00007f6e49e79aa3 in utl::ConfigItem::ConfigItem(rtl::OUString, ConfigItemMode) () from /usr/lib/libreoffice/program/libmergedlo.so #10 0x00007f6e49ea59e8 in SvtSysLocaleOptions::SvtSysLocaleOptions() () from /usr/lib/libreoffice/program/libmergedlo.so #11 0x00007f6e4a29506e in InitVCL() () from /usr/lib/libreoffice/program/libmergedlo.so #12 0x00007f6e4a2959cd in ImplSVMain() () from /usr/lib/libreoffice/program/libmergedlo.so #13 0x00007f6e4941aca6 in soffice_main () from /usr/lib/libreoffice/program/libmergedlo.so #14 0x0000564df860c07b in ?? () #15 0x00007f6e4722920a in __libc_start_call_main (main=main@entry=0x564df860c070, argc=argc@entry=2, argv=argv@entry=0x7ffc488ce848) at ../sysdeps/nptl/libc_start_call_main.h:58 #16 0x00007f6e472292bc in __libc_start_main_impl (main=0x564df860c070, argc=2, argv=0x7ffc488ce848, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc488ce838) at ../csu/libc-start.c:389 #17 0x0000564df860c0b1 in ?? () (found in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005832 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018750) Regards, Rene
Repro. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 52ebc632b3cfa122dcb178cf28d8dbc7c7c57007 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 3 February 2023
well in cppuhelper::ServiceManager::init we could catch and throw only if optional was false, but that'll just go as far as ExtensionManager::synchronize and die with something else. Not sure if its worth it to chase it done or just "WONTFIX" and "don't do that" :-)
(In reply to Caolán McNamara from comment #2) > well in cppuhelper::ServiceManager::init we could catch and throw only if > optional was false, but that'll just go as far as > ExtensionManager::synchronize and die with something else. Not sure if its > worth it to chase it done or just "WONTFIX" and "don't do that" :-) The cppuhelper::Service-/TypeManager initialization generates uncaught exceptions on the grounds that (a) something is probably severely wrong if such fundamental infrastructure is broken and (b) useful error reporting to the user is hard at this stage of the application bootstrap, We could swallow errors (and generate a SAL_WARN) here, either for all or only for non-essential (like the share/extensions) parts, and hope for the best. But as you found, even for something non-essential like share/extensions that will not get very far in practice. (The optional "?..." syntax had been introduced with <https://git.libreoffice.org/core/+/86c9f264f461e814c7e4f899a2d1e54363da053a%5E!/> "#99011# support optional rdb pathes" in 2002, but appears to be unused at least across LO itself. It might or might not be a good means to tell apart the non-essential parts mentioned above.)