LibreOffice in general starts fine on F37, I do it multiple times a day :-)
Maybe something odd happened to your config. Try:

mv ~/.config/libreoffice/ ~/backup.libreoffice.config

and see will it start with the old config removed.

Unfortunately no.

After moving the old config file, I ran $ soffice --safe-mode again, and it still died with "Fatal exception: signal 11". This time it took longer though, maybe it was creating a new config file. The following is the stack trace:

Fatal exception: Signal 11
Stack:
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x39422)[0x7f633c6a8422]
/usr/lib64/libreoffice/program/libuno_sal.so.3(+0x395fb)[0x7f633c6a85fb]
/lib64/libc.so.6(+0x3cb20)[0x7f633c3d8b20]
/usr/lib64/libreoffice/program/libuno_cppu.so.3(+0x180e5)[0x7f633c25f0e5]
/usr/lib64/libreoffice/program/libuno_cppu.so.3(+0x1650c)[0x7f633c25d50c]
/usr/lib64/libreoffice/program/libutllo.so(+0x5842a)[0x7f6339b4d42a]
/usr/lib64/libreoffice/program/libutllo.so(+0x5ae95)[0x7f6339b4fe95]
/usr/lib64/libreoffice/program/libutllo.so(_ZN3utl10ConfigItemC1EN3rtl8OUStringE14ConfigItemMode+0xc3)[0x7f6339b500a3]
/usr/lib64/libreoffice/program/libutllo.so(_ZN19SvtSysLocaleOptionsC1Ev+0x1a0)[0x7f6339b7ef10]
/usr/lib64/libreoffice/program/libvcllo.so(_Z7InitVCLv+0x26f)[0x7f6338cf1d4f]
/usr/lib64/libreoffice/program/libvcllo.so(_Z10ImplSVMainv+0x2f5)[0x7f6338cf27d5]
/usr/lib64/libreoffice/program/libsofficeapp.so(soffice_main+0x12a)[0x7f633c5e604a]
/usr/lib64/libreoffice/program/soffice.bin(+0x10bf)[0x56132b3e00bf]
/lib64/libc.so.6(+0x27510)[0x7f633c3c3510]
/lib64/libc.so.6(__libc_start_main+0x89)[0x7f633c3c35c9]
/usr/lib64/libreoffice/program/soffice.bin(+0x10f5)[0x56132b3e00f5

its crashing very early on trying to figure what locale to use for the UI, possibly the first use of configuration.

what's the output of
$ locale

and is

$ rpm --verify libreoffice-core

silent? or does it report anything?

presumably your config dir is writable or you couldn't have deleted the old config, so it can't be that.

output of $ locate is:
ANG=en_HK.UTF-8
LC_CTYPE="en_HK.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_HK.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="en_HK.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME="en_HK.UTF-8"
LC_ADDRESS="en_HK.UTF-8"
LC_TELEPHONE="en_HK.UTF-8"
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION="en_HK.UTF-8"
LC_ALL=

There is no output from $ rpm --verify libreoffice-core

Libreoffice used to work fine until I ungraded to Fedora 37 :(

Hello,

Somehow I got the Gnome's "Problem Reporting" working again...

It created a report which is linked below. I hope this is helpful to you.

https://retrace.fedoraproject.org/faf/reports/606010/

I have no idea unfortunately. Its a crash early on during startup in the config, but removing the config didn't help and rpm --verify hasn't reported a broken install. It doesn't seen to affect anyone else. Its possible that after it crashes getting the output of journalctl -n 30 might show something of interest

Created attachment 1952405 [details]
output of journalctl -n 30

Hi, thanks for your reply. As you expected, runing $journalctl -n 30 did produce a bunch of stuff. I have attached for you to have a look. Thanks.

unfortunately doesn't help, just a duplicate of the data we already have. There is a more recent version of LibreOffice available, you should at least upgrade to that.

If that still fails, attaching a strace log, like the libreoffice.log the following would create

$ strace -f /usr/lib64/libreoffice/program/soffice.bin > ~/libreoffice.log 2>&1

might help. Maybe there is some permission strangeness for the home dir or something ununusual like that going on.

Created attachment 1952727 [details]
output of strace on soffice

Hi, as per your suggestion, the strace output is attached. Thanks.

When calling ImplSVMain (vcl/source/app/svmain.cxx) -> InitVCL (vcl/source/app/svmain.cxx) -> Desktop::Init (desktop/source/app/app.cxx), which does

>     try
>     {
>         InitApplicationServiceManager();
>     }
>     catch (css::uno::Exception & e)
>     {
>         SetBootstrapError( BE_UNO_SERVICEMANAGER, e.Message );
>     }
> 
>     // Check whether safe mode is enabled
>     const CommandLineArgs& rCmdLineArgs = GetCommandLineArgs();
>     // Check if we are restarting from safe mode - in that case we don't want to enter it again
>     if (sfx2::SafeMode::hasRestartFlag())
>         sfx2::SafeMode::removeRestartFlag();

we apparently catch an exception from within InitApplicationServiceManager before the UNO type manager is initialized (attachment 1952727 [details] contains access to /usr/lib64/libreoffice/program/services.rdb etc., from early stages of InitApplicationSeviceManager(), and access to ~/.config/libreoffice/4/safemode_restart, from the following sfx2::SafeMode::hasRestartFlag(), but not access to /usr/lib64/libreoffice/program/types.rdb etc., from later stages of InitApplicationSeviceManager()).

But before the SetBootstrapError will later be checked and handled in ImplSVMain -> Desktop::Main (desktop/source/app/app.cxx), the code executed in between during ImplSVMain -> InitVCL -> SvtSysLocaleOptions::SvtSysLocaleOptions (unotools/source/config/syslocaleoptions.cxx) already required the UNO type manager to be initialized, and caused a SIGSEGV.

from attachment 1952727 [details]:
> openat(AT_FDCWD, "/usr/lib64/libreoffice/program/services/services.rdb;63ddcd86", O_RDONLY) = 4

Can you please execute in a shell
* `ls -al /usr/lib64/libreoffice/program/services/`
* `file '/usr/lib64/libreoffice/program/services/services.rdb;63ddcd86'`
* `rpm -qf '/usr/lib64/libreoffice/program/services/services.rdb;63ddcd86'`
and provide the output of each?

FEDORA-2023-6282cab755 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-6282cab755

FEDORA-2023-d523f86cee has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d523f86cee

FEDORA-2023-d523f86cee has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

[Looks like Fedora Update System was a bit quick moving this to CLOSED.  I'm still interested in the NEEDINFO:reporter re comment 12, just in case.]

FEDORA-2023-6282cab755 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-6282cab755`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-6282cab755

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FWIW a file ending in semicolon and 8 hex chars like ;63ddcd86 is likely a rpm temp file: https://bugzilla.redhat.com/show_bug.cgi?id=437182#c0 "During rpm upgrade of packages ... it temporarily creates files with names like: /etc/event.d/serial;47d7dd72 before they are moved into their permanent locations."

FEDORA-2023-6282cab755 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Hello Stephan,

Thanks for your replies.

After I ran a $dnf update which downloaded and installed the latest version of Libreoffice, it seems to run again. So, the issue mysteriously fixed itself, as it had mysteriously appeared. Lets hope it stay fixed.