Description: crash log (1 year): https://bin.disroot.org/?77ad04f75939895e#FcX5kva3HrGD1STurr7GLPiit3C5pTbA87NbvdJabkS6 Relevant part: Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Owner in ulock is unknown - possible memory corruption Abort Cause 39693 *** multi-threaded process forked *** crashed on child side of fork pre-exec Steps to Reproduce: Open LibreOffice main build. Sadly no reliable repro steps, it happened once after opening Preferences. But this was not a reliable method to reproduce the crash. Today the crash happened twice in the span of under 10 minutes while having LibreOffice mostly sit idle. What is interesting is also that - despite the crash of soffice - I can continue to work e.g. in a writer document and save the file. Actual Results: soffice quit unexpectedly. Expected Results: No crash. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9c7d3ce813c761b116232bc291e2737c59d383da CPU threads: 8; OS: Mac OS X 13.3; UI render: Skia/Metal; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded
Do you use certificate or specific key? If yes, are they ok? (not expired or something) Could you apply https://wiki.documentfoundation.org/QA/FirstSteps#Corrupted_user_profile and give a new try?
You mean certs as in OpenPGP keys? I have those but I am not using them actively with LibreOffice. Reset user profile and will report back how this evolves.
[Automated Action] NeedInfo-To-Unconfirmed
Peristing after resetting user profile. Unclear repro, the crash happens on different actions or no action at all. Maybe a timing problem, however even the timing when the crash happens differs :( At least the crash seems to be the same: Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Owner in ulock is unknown - possible memory corruption Abort Cause 38669 *** multi-threaded process forked *** crashed on child side of fork pre-exec 1 year: https://bin.disroot.org/?81b7ce7441a1849a#H8Y6smf9iMLhWxxEizTshiYFCg54qHGeQQKMcyV5CtVG
I'd hasard a guess that this is related to bug 146852, just showing up in a different way.
@steve : isn't this a reappearance/re-manifestation of bug 15254 ?
(In reply to Alex Thurgood from comment #6) > @steve : isn't this a reappearance/re-manifestation of bug 15254 ? bug 152524, of course ;-)
Of course, if the issue is that, for whatever reason, a search for gpgme is forked from main, and the corresponding library can't be found, I guess that such a circumstance might cause macOS to determine it is an illegal instruction, especially if it commits the double sin of trying to connect to the internet. Invoking libraries outside of the authorised path is a no-no, but a graceful handling would tell the user about the attempt to exceed the macOS security jail, rather than generate a SIGILL. Still a massive PITA though.
You are of course correct, Alex. *** This bug has been marked as a duplicate of bug 152524 ***