Damage in macOS Silicon Mac installer for LibreOffice 24.2.7?

[Patrick Luby]

Hi everyone,

A user reported that LibreOffice 24.2.7 always crashes on the Mac:

https://old.reddit.com/r/libreoffice/comments/1ggi4sc/libreoffice_2427_is_now_available_the_last/luvd3iw/

I have found the same crash happening on all of my Silicon Mac machines running Sonoma and Sequoia. Installing the Intel installation on my Silicon Mac machines and running with Rosetta 2 doesn’t crash, only the Silicon Mac installation crashes.

This crashing looks like it will affect most Silicon Mac users. Not sure if it will affect Mac App Store users as the Mac App Store is still stuck at LibreOffice 24.2.5 but it is probably prudent to assume that this same crash will happen for Mac App Store builds as well.

So I checked out commit 60d4b3fb5e3fa9db8a102b04aa0025f2052bc02d and did clean release and codesigned builds on the following two platforms but I am unable to reproduce the bug in either of my local builds:

- macOS Sonoma 14.7.1 with Xcode 15.4
- macOS Sequoia 15.1 with Xcode 16.1

I used the following options in my autogen.input:

--with-hamcrest=/opt/hamcrest/hamcrest-2.2.jar
--with-myspell-dicts
--with-lang=de fr ja
--enable-release-build
--enable-online-update
--with-privacy-policy-url=http://blah.com
--with-package-format=dmg
--enable-macosx-code-signing

So is TDF release engineering using any different autogen.input options or using different macOS and/or Xcode versions that me? If yes, I can do a rebuild and see if I can reproduce the crash. If no, does anyone have any ideas what might be different between my builds and TDF’s?

Debug data:

I was able to recodesign the LibreOffice 24.2.7 download and add the necessary entitlement so that I connect lldb. I got a backtrace (see attached lldb_bt.txt file) and it seems to me that the crash is occurring when VCLXMenu::addMenuListener() calls std::unique_lock aGuard( maMutex ) which calls std::mutex::lock().

In the official Silicon Mac installation that crashes, pthread_mutex_lock() is passed a garbage address. It’s always 0x40 so I am guessing that is a data member of some parent class that std::mutex holds and that parent instance is a nullptr. It’s as if std::mutex is failing to fully initialize itself but only in this one official installer. 

Any theories or ideas welcome.

Patrick


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lldb_bt.txt
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20241102/830048c6/attachment.txt>