I cannot reproduce this on either macOS Monterey or Ventura on my Mac Silicon machine. I installed GPGTools from gpgtools.org, created a GPG certificate using the "gpg --full-generate-key" Terminal command and set a password for the certificate.

After that, I saved a new Writer document, checked the "Encrypt with GPG key" in the native Save dialog, the "Select Certificate" dialog appeared with my certificate in the list, selected my certificate and the file was saved successfully.

After restarting LibreOffice, opening the saved file causes GPGTools to display a password dialog. I entered the password that I set when I created the certificate and the file opened successfully.

Note: your sample shows that LibreOffice's third-party gpgme code is executed one of your user installed gpg commands and is waiting for output from the command or for the command to finish.

In other words, the hang is in your user installed gpg commands so I think the data requested in the following comment are still needed:

https://bugs.documentfoundation.org/show_bug.cgi?id=155125#c18

@Steve: I saw the same error message with a key that was created with gnupg-2.1 i386 binary.

Check in your /usr/local/bin/ folder for an old installation of gnupg.

I would check just generally the whole system for all and any bin/gpg and bin/gpg2 executables, and test their arch with the file command from the terminal.

On my system, the presence of the old installation was the reason for my gpg woes. Once I removed it, my life improved significantly, although the signatures that I'd previously created using the older binaries were no longer valid for encrypting anything. I'm guess that in the move to universal arch binaries, something has changed, and although the certs show up as valid on the face of it, they are invalid for encrypting anything, at least in my case.

> Check in your /usr/local/bin/ folder for an old installation of gnupg.

Negative - there is an alias symlink to /usr/local/MacGPG2/bin

Generally it is not a good idea to have multiple gpg instances installed. But that is not the case on my mac (except for the gpgme, that may be coming with LibreOffice?).

@Alex: when you mention old certs being not usable for encryption, are you referring to old OpenPGP keys? If that is the case, keep in mind that weak algorithms may no longer be supported in newer gpg releases. I don't think that that is related to the issue in LibreOffice around the hang / crash though. You can send me an email with the key details and algorithms if you are interested in discussing further, but since that is outside the scope of this bug, we should take that elsewhere.

Patrick: I tried to get a sample from gpg process when recreating the hang, but the output of that was blank. Not sure why that would be.

Another round of testing and this time checking the encrypt box and trying to save a file resulted in:

Error saving the document Untitled 1:
General Error.
General input/output error.

and crash (1 year): https://bin.disroot.org/?a89c6e26fb3ee43f#Ew1C6KiNWg4hsLYJD6fgM1ra7g3MQVX3xxJu8b6SQHJw

The following lines at the bottom of the stack in your crash log is in the same code that causes the crash in tdf#152524. So, once I implement the fix for tdf#152524, I am hoping that it will also fix this bug:

0   libdispatch.dylib             	    0x7ff8034ffe32 _dlock_wait.cold.2 + 24
1   libdispatch.dylib             	    0x7ff8034cf87e _dlock_wait + 98
2   libdispatch.dylib             	    0x7ff8034cf740 _dispatch_unfair_lock_lock_slow + 97
3   libdispatch.dylib             	    0x7ff8034f2007 _voucher_atfork_parent + 147
4   libSystem.B.dylib             	    0x7ff80f4d4788 libSystem_atfork_parent + 38
5   libsystem_c.dylib             	    0x7ff80353d598 fork + 84
6   libgpgme.11.dylib             	       0x1108a88d4 _gpgme_io_spawn + 836

Thanks so much for looking into those long standing OpenPGP issues in LO on macOS.

Sadly even with your patch in main, encrypting with GPG key on save still crashes and throws a General Error.

Actually three windows are opened:

1. Select Certificate dialog (what does that actually do? Should it show my OpenPGP keys? If so, it is not working, I have several secret keys but the dialog shows blank) or does it only list S/MIME certs and if yes, why is that dialog shown at all, when I try to encrypt with GPG?
2. General Error: Error saving the document Untitled 1: General Error. General input/output error.
3. soffice quit unexpectedly (crash log 1 year: https://bin.disroot.org/?4941d3db538e3705#9iGUmknBqPUE6vBqzFcMkk5jRgSqWMtyCyTb6wtyGLix)

Upping importance to high as OpenPGP supported is a feature being marketed, but has been broken on macOS for the longest time.

Created attachment 192370 [details]
2024-02-03 main build showing General Error

(In reply to steve from comment #7)
> Thanks so much for looking into those long standing OpenPGP issues in LO on
> macOS.
> 
> Sadly even with your patch in main, encrypting with GPG key on save still
> crashes and throws a General Error.
> 
> Actually three windows are opened:
> 
> 1. Select Certificate dialog (what does that actually do? Should it show my
> OpenPGP keys? If so, it is not working, I have several secret keys but the
> dialog shows blank) or does it only list S/MIME certs and if yes, why is
> that dialog shown at all, when I try to encrypt with GPG?

I can confirm the crashing, and the bizarre Certificate dialog for me shows 4 or 5 blank entries which are clickable (presumably the certificates previously detected), but any of which, when clicked, causes a crash and launches the recovery dialog.

Created attachment 192383 [details]
Crash after selecting one of the blank certificates in the certificate chooser dialog

Created attachment 192384 [details]
Snapshot of empty GPGTools certificates and personal certificate with missing issuer and date columns

Here is what I found: I created a personal certificate in GPG Keychain.app and I applied the debug patch at the end of this comment in my local build. Then, when I displayed the certificate chooser dialog, I see lots of missing text in the
entries as shown in attachement #11. 

In comparison, below is what the text view entries are actually set to when using my debug patch:

  Row 0:GPGTools Team <team@gpgtools.org>:GPGTools Team <team@gpgtools.org>:05/11/2024
  Row 1:GPGTools Support <support@gpgtools.org>:GPGTools Support <support@gpgtools.org>:05/03/2024
  Row 2:PL <guibomacdev@gmail.com>:PL <guibomacdev@gmail.com>:02/04/2028

Note that rows 0 and 1 are empty and row 2 is missing columns 1 and 2 as shown in attachment #11.

Clearly the tree view's data becomes corrupted some how and, as a result, when y
ou select one of the empty entries, the tree view contains a null pointer for th
e user data:

diff --git a/xmlsecurity/source/dialogs/certificatechooser.cxx b/xmlsecurity/source/dialogs/certificatechooser.cxx
index a54575972c26..bc90554281f0 100644
--- a/xmlsecurity/source/dialogs/certificatechooser.cxx
+++ b/xmlsecurity/source/dialogs/certificatechooser.cxx
@@ -236,6 +236,10 @@ void CertificateChooser::ImplInitialize(bool mbSearch)
             m_xCertLB->set_text(nRow, xmlsec::GetContentPart(xCert->getSubjectName(), xCert->getCertificateKind()), 0);
             m_xCertLB->set_text(nRow, sIssuer, 1);
             m_xCertLB->set_text(nRow, sExpDate, 2);
+fprintf(stderr, "Row %i:%s:%s:%s\n", nRow,
+m_xCertLB->get_text(nRow, 0).toUtf8().getStr(),
+m_xCertLB->get_text(nRow, 1).toUtf8().getStr(),
+m_xCertLB->get_text(nRow, 2).toUtf8().getStr());
 
 #if HAVE_FEATURE_GPGME
             // only GPG has preferred keys
@@ -275,6 +279,9 @@ uno::Sequence<uno::Reference< css::security::XCertificate > > CertificateChooser
         // for encryption, multiselection is enabled
         m_xCertLB->selected_foreach([this, &aRet](weld::TreeIter& rEntry){
             UserData* userData = weld::fromId<UserData*>(m_xCertLB->get_id(rEntry));
+            // tdf#156352 when empty GPGTools key is selected because userData
+            // is a null pointer. Is the underlying list box's memory being
+            // corrupted or is the list box implementation buggy?
             aRet.push_back( userData->xCertificate );
             return false;
         });

I think I can reproduce this on Linux too with the gen backend if there is more than one row added to the the listview

I think the problem is the the list is "sorted" and adding an empty row unexpectedly gets sorted immediately to "row 0" and we end up overwriting the id and text of the previous entry and leave a blank entry on row 0 rather than get the desired outcome.

https://gerrit.libreoffice.org/c/core/+/162993 should suffice to get this case working

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/cf4514d4e7400480174f28dcf502f5b59fe7b085

Resolves: tdf#156352 disable sorting while adding rows

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Caolán McNamara from comment #14)
> I think the problem is the the list is "sorted" and adding an empty row
> unexpectedly gets sorted immediately to "row 0" and we end up overwriting
> the id and text of the previous entry and leave a blank entry on row 0
> rather than get the desired outcome.
> 
> https://gerrit.libreoffice.org/c/core/+/162993 should suffice to get this
> case working

Your fix works in my local master build. The GPGTools rows are now no longer empty and clicking on them no longer crashes.

The fix should be in tomorrow's (05 February 2024) nightly master build. @steve's last crash log looks like another case of tdf#152524 so I think we can mark this bug as resolved/fix and, if @steve still gets tdf#152524 style crashes, we can continue investigation in that bug.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/326246599fa9488caf1ffb33daa75042ab782cb8

Resolves: tdf#156352 disable sorting while adding rows

It will be available in 24.2.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Patrick Luby from comment #16)
> The fix should be in tomorrow's (05 February 2024) nightly master build.

My bad. I meant the 06 February 2024 nightly master build.

Not working here with




Error saving the document Untitled 1:
General Error.
General input/output error.

and Select Certificate list is empty

plus soffice crashes (1 year): https://bin.disroot.org/?f68def9a2701827e#EGfJeu1CgNgoTm77ngBp36WMpmYdiWqn2WKBwMf2szJp

Should the fixes be part of todays build? If yes, should this issue here be re-opened?

Forgot to paste version info. Not working here with:
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6b6849107562b258aa8858e94ff3c07160f07062
CPU threads: 8; OS: macOS 13.6.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

(In reply to steve from comment #19)
> plus soffice crashes (1 year):
> https://bin.disroot.org/
> ?f68def9a2701827e#EGfJeu1CgNgoTm77ngBp36WMpmYdiWqn2WKBwMf2szJp

Unfortunately, that crash log is another case of tdf#152524. The crash is in Apple's "Objective C locks" code. In contrast, the crash @Alex Thurgood and I were seeing was a crash in the LibreOffice code. That bug was nothing too complex like the mysterious tdf#152524.

What I don't understand is why you are seeing tdf#152524 so frequently lately. Didn't the fix for that bug stop the crashing for a while? Or is it just that you hadn't used this particular steps until recently? Or does tdf#152524 crashes only occur after using LibreOffice for some time?

Can you run LibreOffice from command line using the steps at the end of the following tdf#152524 comment? This will print out the names of Objective C classes when they are first used and that will hopefully tell us if some Objective C code somewhere is causing this memory corruption:

https://bugs.documentfoundation.org/show_bug.cgi?id=152524#c44

(In reply to Patrick Luby from comment #16)

> 
> Your fix works in my local master build. The GPGTools rows are now no longer
> empty and clicking on them no longer crashes.
> 
> The fix should be in tomorrow's (05 February 2024) nightly master build.
> @steve's last crash log looks like another case of tdf#152524 so I think we
> can mark this bug as resolved/fix and, if @steve still gets tdf#152524 style
> crashes, we can continue investigation in that bug.

I can confirm that I now see a list of the certificates including my GPG keys in the Certificate Manager.

Tested with (master from 07/02)
Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 467eeda66ee444c846fcd89da1fe064dd06daa9d
CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Raster; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

(In reply to Alex Thurgood from comment #22)
> (In reply to Patrick Luby from comment #16)
> 
> > 
> > Your fix works in my local master build. The GPGTools rows are now no longer
> > empty and clicking on them no longer crashes.
> > 
> > The fix should be in tomorrow's (05 February 2024) nightly master build.
> > @steve's last crash log looks like another case of tdf#152524 so I think we
> > can mark this bug as resolved/fix and, if @steve still gets tdf#152524 style
> > crashes, we can continue investigation in that bug.
> 
> I can confirm that I now see a list of the certificates including my GPG
> keys in the Certificate Manager.
> 
> Tested with (master from 07/02)
> Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
> Build ID: 467eeda66ee444c846fcd89da1fe064dd06daa9d
> CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Raster; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); UI: en-US
> Calc: threaded

I forgot to add that I can also sign the Writer document with one of the GPG keys and obtain a digitally signed document.

Curious that things work as expected for Alex. Two things differ: he has an Apple Silicon Mac on Sonoma while I am on an Intel Mac with Ventura. I can see how Intel Mac + Sonoma does when I get to my other mac in the coming days.

(In reply to steve from comment #24)
> Curious that things work as expected for Alex. Two things differ: he has an
> Apple Silicon Mac on Sonoma while I am on an Intel Mac with Ventura. I can
> see how Intel Mac + Sonoma does when I get to my other mac in the coming
> days.

@steve and @Alex: I found another LibreOffice crash (not the infamous tdf#152524 bug) in the certificate chooser dialog after doing a bunch a steps:

1. Create an empty Writer document and add a digital signature
   in the Digital Signatures dialog
2. File > Save As the document, check the "Encrypt with GPG key"
   checkbox, press Encrypt, and crash in Dialog::ImplStartExecute()

The fix for that crashing bug should be is in the following patch and it should be in tomorrow's (08 February 2024) nightly master build:

https://gerrit.libreoffice.org/c/core/+/163065

(In reply to Patrick Luby from comment #25)

Hi @Patrick,

> @steve and @Alex: I found another LibreOffice crash (not the infamous
> tdf#152524 bug) in the certificate chooser dialog after doing a bunch a
> steps:
> 
> 1. Create an empty Writer document and add a digital signature
>    in the Digital Signatures dialog
> 2. File > Save As the document, check the "Encrypt with GPG key"
>    checkbox, press Encrypt, and crash in Dialog::ImplStartExecute()
> 
> The fix for that crashing bug should be is in the following patch and it
> should be in tomorrow's (08 February 2024) nightly master build:
> 
> https://gerrit.libreoffice.org/c/core/+/163065

I'll check that build tomorrow - with a bit of luck, it might solve what I suspect is a similar crash when using the "Sign" button to try and sign with a certificate that already "seems to appear" (as a blank entry) in the list of Digital Signatures associated with a document, cf. bug 159612, "If I click on the "Sign" button in this state, I get a repeatable crash, and the recovery dialog is started."

Still seeing "Error saving the document Untitled 2: General Error. General input/output error." when following steps from op along with a crash (1 year): https://bin.disroot.org/?fba581badd007984#BoCmMZHtPAzWqdCBFSRpY9vHEAheFwFDXAMVLtKyJQCh

*** Bug 153626 has been marked as a duplicate of this bug. ***

(In reply to steve from comment #27)
> Still seeing "Error saving the document Untitled 2: General Error. General
> input/output error." when following steps from op along with a crash (1
> year):
> https://bin.disroot.org/
> ?fba581badd007984#BoCmMZHtPAzWqdCBFSRpY9vHEAheFwFDXAMVLtKyJQCh

Argh! The gpgme code's fork() is still being called on the main thread.

I must be doing something wrong in my last patch so I will see if I can force libdispatch to run fork() in a separate thread.

(In reply to Patrick Luby from comment #29)
> Argh! The gpgme code's fork() is still being called on the main thread.
> 
> I must be doing something wrong in my last patch so I will see if I can
> force libdispatch to run fork() in a separate thread.

Clarification: the crash in comment #28 is another case of tdf#152524.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 43d962c27b6efb04d22b05ad8dec08f6056078a0
CPU threads: 8; OS: macOS 13.6.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Verified. Saving the document with the option "Encrypt with GPG key" finally shows a list of public keys and the encryption is done with the selected key.

Sadly further testing resulted in crashes:

1. open writer and type "test" into new document
2. cmd + s to open save dialog
3. tick option "Encrypt with GPG key" and press save
-> crash, crash log (1 year): https://bin.disroot.org/?bb528849f75e0a3d#BfRhoJqEjDv2KkUUN8wTthKi455u3svWQGvqTtHLDByt

along with error dialog: Error saving the document Untitled 1:
General Error.
General input/output error.

It is funny, because at least once the process worked as expected and the key list of public keys was shown and an encrypted document was saved which asked for the yubikey to be connected on open, where the OpenPGP secret key part is stored.

Then in the next test round I am not seeing the public key list and LO crashes and shows the error dialog. In a third round the crash happens again.

Hope the crash log is useful. Maybe all those crashes are still cases of https://bugs.documentfoundation.org/show_bug.cgi?id=152524 after all and while LO no longer crashes on open, the crash now happens as soon as any OpenPGP operation is called?

(In reply to steve from comment #31)
> It is funny, because at least once the process worked as expected and the
> key list of public keys was shown and an encrypted document was saved which
> asked for the yubikey to be connected on open, where the OpenPGP secret key
> part is stored.
> 
> Then in the next test round I am not seeing the public key list and LO
> crashes and shows the error dialog. In a third round the crash happens again.
> 
> Hope the crash log is useful. Maybe all those crashes are still cases of
> https://bugs.documentfoundation.org/show_bug.cgi?id=152524 after all and
> while LO no longer crashes on open, the crash now happens as soon as any
> OpenPGP operation is called?

You are correct: the crash is still a case of tdf#152524. But it is now in a separate thread, not the main thread. What is really noticeable to me about your latest crash is that there is only one thread listed and that is the same old fork() in gpgme.

What I don't understand is where is the main thread in your latest crash log? The main thread is blocked waiting for the thread that crashed so the main thread should still be alive at the time of crash. But it isn't. Instead, the gpgme thread is thread 0.

That makes me suspect that the gpgme code corrupts memory after some number of times gpg is executed. My code only tries to ensure that LibreOffice doesn't execute gpg until a previous gpg is completely finished. That seems to only delay the inevitable so maybe your particular OpenPGP data or configuration trigger a bug in gpgme code?

Not sure. I restarted to make sure nothing system wise got stuck or into hang resulting in all additional attempts to trigger the crash but ran into the crash again on first attempt after restart.

Nothing special about my gpg setup I'd say. Have multiple secret keys of which one resides on a yubikey.

It is fascinating that with all those attempts the public key list only over showed a single time for me and I was even able to created an encrypted document in that case. All further attempts failed and resulted in a crash and error message.

If you think it would be helpful, happy to screenshare and demo the crash.

(In reply to steve from comment #33)
> Not sure. I restarted to make sure nothing system wise got stuck or into
> hang resulting in all additional attempts to trigger the crash but ran into
> the crash again on first attempt after restart.

So nothing has worked since the following "run in a Terminal" workaround?:

https://bugs.documentfoundation.org/show_bug.cgi?id=152524#c30

Does that workaround still work with tomorrow's (19 February 2024) nightly master build?

Tried executing in terminal:

 export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
  /Applications/LibreOffice.app/Contents/MacOS/soffice

and save as + Encrypt with GPG key option resulting in crash, key list showing but being empty and General input/output error.
Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: macOS 13.6.4; UI render: Skia/Metal; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded

Tried the same with:

 export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
  /Applications/LibreOfficeDev.app/Contents/MacOS/soffice

also crashing, no key list dialog at all and General input/output error.

There is terminal output which I am sharing:

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
  /Applications/LibreOfficeDev.app/Contents/MacOS/soffice
warn:configmgr:3122:99786:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///Users/username/Library/Application%20Support/LibreOfficeDev/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu26662sool.tmp/Addons_AOO4.xcu"
warn:configmgr:3122:99786:configmgr/source/xcuparser.cxx:904: ignoring modify of unknown set member node "ToolBarItems" in "file:///Users/username/Library/Application%20Support/LibreOfficeDev/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu26662sool.tmp/Addons_AOO4.xcu"
warn:configmgr:3122:99786:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///Users/username/Library/Application%20Support/LibreOfficeDev/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu26662sook.tmp/Addons.xcu"
warn:i18nlangtag:3122:99786:i18nlangtag/source/isolang/isolang.cxx:1418: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016
warn:i18nlangtag:3122:99786:i18nlangtag/source/isolang/isolang.cxx:1418: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016
warn:vcl.skia:3122:99786:vcl/quartz/cgutils.mm:105: Default MTLDevice is "AMD Radeon Pro 560"
warn:i18nlangtag:3122:99786:i18nlangtag/source/isolang/isolang.cxx:1418: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016
warn:i18nlangtag:3122:99786:i18nlangtag/source/isolang/isolang.cxx:1418: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016
warn:unotools.misc:3122:99786:unotools/source/misc/mediadescriptor.cxx:372: url: 'private:factory/swriter' com.sun.star.ucb.ContentCreationException message: "No Content Provider available for URL: private:factory/swriter" eError: (com.sun.star.ucb.ContentCreationError) NO_CONTENT_PROVIDER
warn:unotools.config:3122:99786:unotools/source/config/lingucfg.cxx:399: unexpected property handle
warn:unotools.config:3122:99786:unotools/source/config/lingucfg.cxx:399: unexpected property handle
warn:vcl:3122:99786:vcl/osx/salmenu.cxx:706: unmapped accelerator key
warn:legacy.tools:3122:99786:sfx2/source/control/bindings.cxx:1770: No cache for OfficeDispatch!
2024-02-19 12:52:29.544 soffice[3122:99786] +[CATransaction synchronize] called within transaction
2024-02-19 12:52:29.680 soffice[3122:99786] +[CATransaction synchronize] called within transaction

(In reply to steve from comment #35)
> 2024-02-19 12:52:29.544 soffice[3122:99786] +[CATransaction synchronize]
> called within transaction
> 2024-02-19 12:52:29.680 soffice[3122:99786] +[CATransaction synchronize]
> called within transaction

These messages are new to me. I run LibreOffice from the Terminal frequently never see these messages. I assume these "CATransactions" have something to do with animations. Maybe from Skia/Metal?

None of my hacky attempts to fix this are in LibreOffice 24.2.x so can you try running today's night build in a Terminal with both Skia checkboxes unchecked with the "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES" trick?

What I am trying to figure out is why the "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES" trick no longer works. Maybe I am remembering wrong, but it seemed like that trick work for you for some period of time and, since then, nothing works.

To me, it feels like we are back at square one and maybe my latest patches are making things worse rather than better. So I am inclined to revert my latest patches and see if we can get back to where the "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES" trick worked again if disabling Skia has no effect.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ef9e1116d1100af50d7b74dcee5155c81b7b50fb
CPU threads: 8; OS: macOS 13.6.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Without changing anything in regards to skia settings and without opening LO from terminal, did a test. After confirming the "Encrypt with GPG key" dialog the beachball showed for a few seconds. And while I was waiting for the error dialog, I was pleasantly surprised with the public key list showing as expected.

After selecting a key the encrypted document was created successfully.

Additional attemps of the same steps result in crash https://bin.disroot.org/?e1ec55119ff3f253#73M1gN2HxzjQBcFGU3iDGDzKGw1DfxiMrWCiYksuDKuT and error message.

Next: disable skia in Settings > View > Use Skia for all rendering. (Skia is currently disabled.) -> Crash + error.

Next: skia disabled + launch with
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
  /Applications/LibreOfficeDev.app/Contents/MacOS/soffice
after looking at the beachball for ~55 seconds the public key dialog shows.
Terminal output is: https://bin.disroot.org/?594ecae25ad43398#F31K9L79WLrjEUM6iFNJqh55EYCcGvqfmwWBLtB7J2qq
After picking a public key, encryption did not succeed and dialog was shown about problem with the public key in question. Lets ignore that until the rest works more reliably.

Another test round of skia disabled + launch with terminal command results in an immediate crash.

(In reply to steve from comment #37)
> Another test round of skia disabled + launch with terminal command results
> in an immediate crash.

OK. Let's forget about the "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES" trick for now.

I've been trying to brainstorm what could cause the "LibreOffice crashes sooner and sooner" behavior that you describe. I now see a "crashed on child side of fork pre-exec" line in your recent crash logs so maybe the gpg command is crashing and the crash is bubbling up to LibreOffice.

I did some online searching and gpg (GPGTools in my case) launches a background process called "gpg-agent" that stays running even after LibreOffice quits or crashes.

So, when LibreOffice crashes (either 24.2 or the nightly build), can you kill the gpg-agent background process before you relaunch LibreOffice using the following steps? Does that make LibreOffice run longer before crashing?:

1. Open a Terminal window and execute the following command:
     ps -ef | grep gpg-agent | grep -- --homedir

2. The output should look similar to the following:
     501 39658     1   0 12Feb24 ??         0:24.96 gpg-agent --homedir /Users/pluby/.gnupg --use-standard-socket --daemon

3. Kill the "gpg-agent" command by executing the following command. Note: replace ### with the second number from the left in the output from step 2:
     kill ###

4. Rerun the command in step 2. If step 3 was successful, there should be no output.

5. Launch LibreOffice

1. open LO writer, type "test" save as and tick "Encrypt with GPG key" option
2. crash (1 year: https://bin.disroot.org/?cd5b8b61e3377f60#4JLHgQY1oCy6pcieb2GJgTE22r6wV2Vxr2fTVyUWaXGj)
3. ps -ef | grep gpg-agent | grep -- --homedir
	  501  1264     1   0 10:29AM ??         0:00.63 gpg-agent --homedir /Users/username/.gnupg --use-standard-socket --daemon
4. kill  1264 
5. confirmed re-running commmand from #3 results in no output
6. repeat #1
7. crash (1 year: https://bin.disroot.org/?91362ad541b94082#4zAUuABTbMUJoFMvwdJt7Sob9GMpzeHKTwcJMkDGwvP7)

(In reply to steve from comment #39)
> 5. confirmed re-running commmand from #3 results in no output
> 6. repeat #1
> 7. crash (1 year:
> https://bin.disroot.org/
> ?91362ad541b94082#4zAUuABTbMUJoFMvwdJt7Sob9GMpzeHKTwcJMkDGwvP7)

OK. But was the second crash immediate, or did you make it to the Encrypt button before crashing?

I was wondering about you asking when the crash happened earlier.

In all tests I do reach the save dialog and tick the "Encrypt with GPG key" option. Any crashes reported in recent testing happend after clicking OK in the save as dialog.

The crashes that happened in the past when opening LibreOffice seem to no longer happen.

(In reply to steve from comment #41)
> I was wondering about you asking when the crash happened earlier.
> 
> In all tests I do reach the save dialog and tick the "Encrypt with GPG key"
> option. Any crashes reported in recent testing happend after clicking OK in
> the save as dialog.
> 
> The crashes that happened in the past when opening LibreOffice seem to no
> longer happen.

OK. If you are consistently getting to the same crash point each time (i.e. clicking the Save button in the Save As dialog) that is good to know. I somehow got the impression that you were able to get as far as clicking the Save button in the Save As dialog and it would crash. Then, when you restarted LibreOffice, you would see the same crash immediately like some sort broken state was accumulating between launches.

I committed a small change that will be in tomorrow's (23 February 2024) nightly master build (see https://bugs.documentfoundation.org/show_bug.cgi?id=152524#c57). It won't fix anything but it reverts my last attempted fix so that your crash logs will show the main thread so I can see where in the LibreOffice code the crash occurs. My last attempted fix executed the gpg command on its own separate thread and since the crash corrupts memory, there is no main thread stack in your latest crash logs so I couldn't tell what LibreOffice code was running.

Anyway, with tomorrow's nightly master build, can you post a new crash log when you click the Save button in the Save As dialog?

Also, can you try digitally signing a document without encryption? That process also displays the Select Certificate dialog so if digital signing also crashes, that might give me some ideas of what to do next.

Thanks for not giving up easily on this clusterjoy.

The crashes in regards to the save dialog are very consistent. They only ever happen *after* ticking the GPG encrypt checkbox *and then* clicking "save". The only inconsistency (which happened once) was, when I indeed saw the key list dialog and was able to successfully save an encrypted file. I have no idea, why it work as expected that single time.

Here is a crash log with todays main build (1 year): https://bin.disroot.org/?9d962d276456f000#E3kHTNMSaQthwKKUSJn1FbKUhTk3by4L8xWAg4AinM2M

Attempting to digitally sign the document via File > Digital Signatures > Digital Signatures … shows an empty dialog despite various sec/pub keys existing on my mac. Soon after a crash happens (1 year): https://bin.disroot.org/?ed7a1821187e34f8#Cbk5qKFJps4KyLVdNiDrZBUZK4Qyd9BgzL3XytrWLrcC

Let me know if you want anything else tested, hope the new crash logs are useful.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3b73071f7a7fcf80547da81e5effe4ed6018bbb4
CPU threads: 8; OS: macOS 13.6.4; UI render: default; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Created attachment 192737 [details]
gpgme log after running with "export GPGME_DEBUG=3:~/mygpgme.log"

(In reply to steve from comment #43)
> Let me know if you want anything else tested, hope the new crash logs are
> useful.

Very helpful. They both crash when executing the gpg command but they are also slightly different. But in both crashes, the lowest common LibreOffice call is CertificateImpl::setCertificate() which calls GpgME::Context::exportPublicKeys(). That's one of the links between LibreOffice and gpgme code. I still need to walk through that LibreOffice code and see if anything jumps out at me.

In the meantime, I was looking at gpgme's debug logging:

https://www.gnupg.org/documentation/manuals/gpgme/Debugging.html

Attachment #192737 [details] is the log file output when I did the following:

1. In the Terminal, invoke the following commands to run the LibreOffice nightly build:
  export GPGME_DEBUG=2:~/mygpgme.log
  /Applications/LibreOfficeDev.app/Contents/MacOS/soffice
2. Open a Writer document and select the File > Digital Signatures > Digital Signatures... menu item. If I understand correctly, this should crash LibreOffice on @steve's machine.
3. Open the mygpgme.log file in your home folder

Important note: the mygpgme.log file will contain the names and e-mails of your keys in GPGTools. So, before you upload the mygpgme.log file, be sure to sanitize any sensitive names and/or e-mails.

Followed your three steps.

LO does show an empty dialog "Digital Signatures" (unexpected) and briefly after (without any dialog interaction) crashes (1 year: https://bin.disroot.org/?4b322ca330a5a239#GzpaKWdpqqfQu9nRvDdG3kP66TtwQoE89aCZ1r92njTr)

mygpgme.log says version 1.20.0
Was expecting 1.18 as per https://bugs.documentfoundation.org/show_bug.cgi?id=152524#c16 but it seems gpgme was updated to version 1.20.0. 1.23.2 seems to be the latest stable as per https://gnupg.org/download/index.html#gpgme. Wondering if that could be relevant.

This is mygpgme.log until the crash happened and I closed LO:

2024-02-24 14:03:30 gpgme[6785.1a81] gpgme_debug: level=2
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme_check_version: call: req_version=(null), VERSION=1.20.0-unknown
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme_check_version_internal: call: req_version=(null), offset_sig_validity=60
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo: gpgconf='/usr/local/MacGPG2/bin/gpgconf'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:       gpg='/usr/local/MacGPG2/bin/gpg'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:     gpgsm='/usr/local/MacGPG2/bin/gpgsm'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo: gpg-agent='/usr/local/MacGPG2/bin/gpg-agent'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:  scdaemon='/usr/local/MacGPG2/libexec/scdaemon'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:   dirmngr='/usr/local/MacGPG2/bin/dirmngr'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:  pinentry='/usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:   homedir='/Users/username/.gnupg'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:   sockdir='/Users/username/.gnupg'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:     agent='/Users/username/.gnupg/S.gpg-agent'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:       ssh='/Users/username/.gnupg/S.gpg-agent.ssh'
2024-02-24 14:03:30 gpgme[6785.1a81] gpgme-dinfo:   dirmngr='/Users/username/.gnupg/S.dirmngr'

Tests done in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3b73071f7a7fcf80547da81e5effe4ed6018bbb4
CPU threads: 8; OS: macOS 13.6.4; UI render: default; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

(In reply to steve from comment #46)
> This is mygpgme.log until the crash happened and I closed LO:
> 
> 2024-02-24 14:03:30 gpgme[6785.1a81] gpgme_debug: level=2

Unfortunately, your "debug level 2" log is the same as mine so it seems that we need at least "debug level 3" to see more detailed steps to log.

Is it possible to run with a higher debug level and search and replace any names and e-mail addresses? What I see in my log in attachment #192737 [details] is a bunch of "gpgme:keylist_colon_handler:" messages. Then each is followed by what looks like a loop of "gpgme_op_keylist_next:" messages.

If don't want to skip searching and replacing in the log, would it be possible to post the message lines from the end of the log up to, but not including, the last "gpgme:keylist_colon_handler:" message (i.e. everything after the last message any names or e-mails)?

I don't want nor need to see any names or e-mails, I just need to know if you ever see any "gpgme:keylist_colon_handler:" messages in your log. The names and e-mails in a "debug level 3" log only indicate that gpgme sucessfully ran the gpg command and gpg returned some list of certificates.

Do you happen to know how to adjust the gpgme log level?

(In reply to steve from comment #48)
> Do you happen to know how to adjust the gpgme log level?

I found a typo in step 1 in comment #c45. Here are the corrected steps. Note: I replace the "2:" with "3:" in the setting of GPGME_DEBUG:

  export GPGME_DEBUG=3:~/mygpgme.log
  /Applications/LibreOfficeDev.app/Contents/MacOS/soffice

1. Terminal
export GPGME_DEBUG=3:~/mygpgme.log
/Applications/LibreOfficeDev.app/Contents/MacOS/soffice
2. Open a Writer document and select the File > Digital Signatures > Digital Signatures... menu item
    Digital Signatures shows empty, but does not crash immediately
3. Click "Sign Document": this opens dialog "Select Certificate" which shows a list of all secret keys
4. select an OpenPGP secret key and click "sign": This results in the "Digital Signatures" dialog being fillied with the information from that user ID
5. closing that document results in LibreOffice showing a banner above the writer document "This document is digitally signed and the signature is valid."

See no crash and everything behave as expected.

Repeat steps starting LibreOfficeDev without Terminal and seen immediate crash after clicking "Sign Document" 🤯

One more round starting from terminal:
Select Certificate shows with no problem, signing works.

One more round without terminal:
Signing worked as expected 😵‍💫 and another successful test round afterwards.

I guess that is progress. But it is not helpful to even begin understanding under which circumstances the crash happens. Welcome to the hell that is debugging OpenPGP problems I guess.

(In reply to steve from comment #50)
> export GPGME_DEBUG=3:~/mygpgme.log
> See no crash and everything behave as expected.
> 
> Repeat steps starting LibreOfficeDev without Terminal and seen immediate
> crash after clicking "Sign Document" 🤯

This is very, very interesting data and it might be a small breakthrough. I am thinking that enabling logging at a verbose enough level is slowing the gpgme code a bit (I would think only slightly since it is probably just doing printf() to a file with existing data) and that is what is stopping the crashing.

Usually this is a symptom of a "race condition" which is two threads/processes/etc. both using a shared resource such as memory or a file and the result depends on which competing thread/process/etc. gets to the resource first.

So give me a few days and I will read through the LibreOffice code that both of your last crashes converge in and see if I can find something that looks suspicious. I know that gpgme communicates to the gpg command that it executes via some files and/or pipes so maybe the LibreOffice code is reading ahead before the gpg command has had a chance write its output to the files and/or pipes? Just a wild theory at this point but overall this does give me something new to investigrate so that's progress.

Since I didn't include the crash log from my last testing I did another test round just to be sure to provide accurate crash logs.

This is a crash after starting without terminal: https://bin.disroot.org/?8be3a3e923b14fb8#6XTcvEUXxGyWBAfmntL33C8bv9A8VMvpSAQjHF5HVFZ

Starting from terminal: no crash

Starting again without terminal: no crash

You are def onto something here. Amazing.

Sorry, last results may be contradicting the theory. But so far I have zero crashes when starting from terminal. So might still be valid.