Download it now!
Bug 127619 - macOS -- LibreOffice crash within 40s after opening app when online update automatically enabled, or with check from the Extension manager -- https certificate issues
Summary: macOS -- LibreOffice crash within 40s after opening app when online update au...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.0.1 rc
Hardware: All Mac OS X (All)
: highest major
Assignee: Stephan Bergmann
URL:
Whiteboard: target:6.5.0 target:6.3.5 target:6.4.0
Keywords: bisected, regression
: 127613 127818 127894 127997 127999 128346 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-09-18 10:22 UTC by pjakruger
Modified: 2020-01-28 21:36 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:


Attachments
Extension Manager (75.30 KB, image/png)
2019-09-19 13:58 UTC, pjakruger
Details
Trace - Thread 6 UpdateCheckThread crashed (96.75 KB, text/plain)
2019-10-08 22:09 UTC, Uwe Auer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pjakruger 2019-09-18 10:22:42 UTC
Description:
I tried the following versions:
- LibreOffice_6.1.0.1_MacOS_x86-64
- LibreOffice_6.2.0.1_MacOS_x86-64
- LibreOffice_6.3.1_MacOS_x86-64
- LibreOffice_6.3.2.1_MacOS_x86-64


Steps to Reproduce:
1. Download .dmg file
2. Double click .dmg file 
3. Drag LibreOffice.app to Applications
4. Double click LibreOffice.app
5. Wait for about 40s -> Crash

Actual Results:
LibreOffice Document Recovery pops up
Due to an unexpected error, LibreOffice crashed. ....

Expected Results:
LibreOffice should not crash after 40s


Reproducible: Always


User Profile Reset: Yes



Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: StartModule
[Information guessed from browser]
OS: Mac OS X (All)
OS is 64bit: no
Comment 1 Julien Nabet 2019-09-18 13:53:43 UTC
Could you give a try to:
https://wiki.documentfoundation.org/QA/FirstSteps
?

Also:
- do you have any accessibility features enabled? If yes, could you disable them for the test?
- did you install specific fonts? If yes could you uninstall them for the test?

Finally, if you still reproduce this, could you attach a backtrace?
(see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS:_How_to_get_debug_information)
Comment 2 pjakruger 2019-09-18 15:36:38 UTC
Thank you for your reply. 

1. I deleted my profile and the crash still occurs

2. Under About I get the following:
Version: 6.1.0.1
Build ID: 378e26bd4f22a135cef5fa17afd5d4171d8da21a
CPU threads: 8; OS: Mac OS X 10.13.6; UI render: default; 
Locale: en-ZA (en_ZA.UTF-8); Calc: group threaded

3. Since LibreOffice does not crash back to macOS, I do not get a crash report.

4. I have no accessibility features enabled that I am aware of

5. I have not installed any specific fonts
Comment 3 QA Administrators 2019-09-19 03:17:47 UTC Comment hidden (obsolete)
Comment 4 Alex Thurgood 2019-09-19 08:06:29 UTC
@pjakruger: the version of LO you are using that you report in comment 2 is obsolete (LO6101), as is LO6201.

Current releases are either :

LO6271

or

LO6312

Just on a hunch. Crashes on startup or shortly thereafter are often linked to a malfunctioning extension.

Could you list the LO extensions that you have.
Comment 5 Alex Thurgood 2019-09-19 10:08:20 UTC
@pjakruger : do you have the automatic update feature activated in your LO preferences, and if so, which settings have you chosen ?
Comment 6 pjakruger 2019-09-19 13:58:45 UTC
Created attachment 154295 [details]
Extension Manager

The extensions installed
Comment 7 pjakruger 2019-09-19 14:01:32 UTC
I have attached a screenshot of Extension Manager
Comment 8 QA Administrators 2019-09-20 03:06:14 UTC Comment hidden (obsolete)
Comment 9 Alex Thurgood 2019-09-20 07:51:13 UTC
Still need info on whether automatic updates are enabled, and if so, what those settings are.
Comment 10 pjakruger 2019-09-20 17:09:50 UTC
Sorry, yes, it is enabled for once a week. I also downloaded and installed the latest version with the same results
Comment 11 QA Administrators 2019-09-21 03:08:26 UTC Comment hidden (obsolete)
Comment 12 Roman Kuznetsov 2019-09-21 13:48:36 UTC
no crash in macOS 10.14.6 in

Version: 6.2.7.1
Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US
Calc: threaded

nor in 

Version: 6.4.0.0.alpha0+
Build ID: 98519e6e4da252c717e2018d4800a00115101bc3
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: GL; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-09-18_07:14:28
Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US
Calc: threaded
Comment 13 steve -_- 2019-09-23 16:54:20 UTC
Unable to reproduce. Seems to be related to specific user configuration.

@pjakruger:
    1. Are the crashes persisting if you diable the automatic update checks?
    2. Does temporarily removing all extensions prevent LO from crashing?

So 6.3.1.2 still crashes without showing any crash report? Is LO fully closed once the crash happens or is it stuck hanging and you have to force quit?
Comment 14 Julien Nabet 2019-09-27 09:41:25 UTC
*** Bug 127818 has been marked as a duplicate of this bug. ***
Comment 15 Julien Nabet 2019-09-27 10:03:34 UTC Comment hidden (obsolete)
Comment 16 steve -_- 2019-09-28 08:21:34 UTC
Adding repro steps and version info from https://bugs.documentfoundation.org//show_bug.cgi?id=127818

When starting LO by clicking an associated file, LO crashes 10-20 seconds after start. When it restarts, the "Document recovery" window is shown. After successful recovery, the document is opened (e.g. in Calc). Then, after 10-20 seconds, LO crashes again.

Steps to Reproduce:
1. Open LO on it's own or by clicking on an associated file


Actual Results:
After 10-20 seconds, LO crashes and restarts with the "Document recovery" window showing.

Expected Results:
Application should not crash


Reproducible: Always


User Profile Reset: Yes


Additional Info:
[Version: 6.3.1.2
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU threads: 8; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
Locale: de-AT (de_AT.UTF-8); UI-Language: en-US
Calc: threaded

@pjakruger: Are you also using macOS 10.13.6 as two people tested 10.14.6 and were unable to reproduce the problem. Wondering if this is limited to 10.13.
Comment 17 pjakruger 2019-09-29 19:09:43 UTC
Good day. Sorry for the late reply. Yes, I am on macOS 10.13.6. The problem is the auto update. Before LO crashes, I was able to disable the online update. The trick seems to be to first click Apply, then Ok and then exit LO (before crashing). However, just clicking on Check Now immediately triggers the crash.
Comment 18 QA Administrators 2019-09-30 02:52:56 UTC Comment hidden (obsolete)
Comment 19 tiago.montes 2019-10-01 01:24:08 UTC
Hello all,

Chiming in with my experience which seems to be similar, which I just logged in (https://bugs.documentfoundation.org/show_bug.cgi?id=127894) -- before I found this bug.

I'm running 10.12.6 but, in general, the behaviour is the same: self-crash with no interaction after 35 seconds -- tried several versions and only the older 6.0.x seems ok. Newer versions no longer crash after disabling check for updates. Full details on the bug I logged.

Happy to contribute with diagnostic info.

Thanks.
Comment 20 Alex Thurgood 2019-10-01 05:39:56 UTC
*** Bug 127894 has been marked as a duplicate of this bug. ***
Comment 21 Alex Thurgood 2019-10-01 05:41:08 UTC
*** Bug 127613 has been marked as a duplicate of this bug. ***
Comment 22 Alex Thurgood 2019-10-01 05:41:48 UTC
Given the number of duplicates, confirming.
Comment 23 tiago.montes 2019-10-01 09:46:16 UTC
Alex Thurgood,


Thanks for the quick follow-up. May I humbly suggest:

1. Removing the [High Sierra 10.13.6] text from the summary.
   It is misleading, given that I'm observing it in macOS Sierra 10.12.6.

2. Changing the earliest affected version to 6.1.0.1.
   Still shows this behaviour on my system, 6.0.7.3 being the most recent version that does not seem to fail.


Post-Scriptum
-------------
I did quick search for "severity = major", "priority = high", "os = macOS" and came up with a list of 20 bugs, including this one. I respectfully argue that, in comparing this bug with others on that list, I would be inclined to raise the "severity", at least: if a systematic crash that prevents the tool from being used isn't "critical", I'm not sure what would be, other than "data corruption/destruction" (I tried finding the definitions for different severity/priority levels, but couldn't, so I might be missing something here!).

Again thanks!
Comment 24 Alex Thurgood 2019-10-07 10:16:40 UTC
(In reply to tiago.montes from comment #23)

@tiago : I would personally be inclined to agree, however, the problem can be worked around by turning off automatic updates. 

As I don't make the rules, merely attempt to interpret them, I am wary of upping priority only to have it brought back down again for reasons such as the one above.
Comment 25 V Stuart Foote 2019-10-07 13:23:56 UTC
*** Bug 127999 has been marked as a duplicate of this bug. ***
Comment 26 V Stuart Foote 2019-10-07 13:28:18 UTC
*** Bug 127997 has been marked as a duplicate of this bug. ***
Comment 27 V Stuart Foote 2019-10-07 13:37:52 UTC
Back at 5.2 we had issues with Windows XP use of the libcurl update checks and posting crash dumps.

The check for update still uses cURL, any recent changes there on the macOS flavors? Either checking for updates, or for posting crash reports (though I didn't think we did for macOS).
Comment 28 Alex Thurgood 2019-10-07 16:07:57 UTC
(In reply to V Stuart Foote from comment #27)

> The check for update still uses cURL, any recent changes there on the macOS
> flavors? Either checking for updates, or for posting crash reports (though I
> didn't think we did for macOS).

Can't answer wrt updates, but we certainly don't do crash reports in the sense that LO's crashreporter isn't activated. When an app crashes on macOS, the OS provides an Apple system dump of the process at the moment it crashed, and offers to send this to Apple...which I imagine most people ignore, or perhaps they do send it to Apple, but who knows what happens to it after that.

In a separate bug report I re-closed today, someone posted the Apple trace dump, in which clearly the update thread check was fingered as the culprit at the time of the crash. Unfortunately, we'd probably need a debug version output to find out more.
Comment 29 tiago.montes 2019-10-08 09:35:08 UTC
(In reply to Alex Thurgood from comment #24)
> (In reply to tiago.montes from comment #23)
> 
> @tiago : I would personally be inclined to agree, however, the problem can
> be worked around by turning off automatic updates. 
> 
> As I don't make the rules, merely attempt to interpret them, I am wary of
> upping priority only to have it brought back down again for reasons such as
> the one above.

Thanks for acknowledging this.

A counter-argument could be that while the failure can be worked around by disabling auto-update checks, I'd say that either an existing and experienced user or, in particular, a user new to LibreOffice have no obvious way/hint/indication of that fact.
With that, their experience will be very unwelcoming to say the least... :( It's not like LibreOffice crashes and pops a friendly message saying "Hey, I've crashed, but I won't if you change the settings like so and so"!

Respectfully sharing a counter-argument. Not insisting on the topic. :)

PS: Maybe this derives from the fact that I could not find a guide/reference defining what a given severity means and how it should be applied to a particular issue. Is there such a thing?
Comment 30 lauhub 2019-10-08 10:19:10 UTC
Bug is also present under macOS 10.14 Mojave

---disclaimer: the words below are about severity

I agree with @Tiago that severity is *critical*: I am an experienced user and just spent *hours* finding what was wrong (I will not tell you here all I did to solve the problem without success until I found this topic).

Do not expect for a second a lambda user to solve this. He will just do one thing: trash LO to the bintray.

He will not open LO preferences, he will not check/uncheck any checkbox, he will not search on the Web about this.

Respecting the rules is important. But there is one above all the other ones in software development : inform end-user what did not work.

The lack of message here is obviously critical.

Spending time discussing "major vs critical" just prevent the problem from being corrected asap.

I apologize not being as diplomatic as Tiago but wasting so many time did not help me ;-)
Comment 31 andre78ch 2019-10-08 15:15:17 UTC
To give more info:

On my MacOS 10.13.6, LO worked fine for sometime. This crash bug did not appear immediately after the OS update from 10.12 (system on which the bug also appears anyways, as well as on 10.14). It started shortly after the 2019-005 security update by Apple; perhaps already after the 2019-004 (14.08.2019) security update. 

The first time I've experienced the crash was induced by clicking on "Check for Updates" in the Extension Manager.

Could it be that some new security gate added to MacOS brings LO to crash when attempting to connect to the web?

Has anyone tried other LO functions implying under the hood web requests?


PS: My opinion as an intermediate user (No knowledge of C or C++, but R, Python, Javascript programer used to search on StackOverflow and forums): Whatever it is, the workaround works, but, I agree, it is very well hidden (it cost me several hours to find out; I've switched to Scrivener during crash time and seriously considered remaining with Scrivener despite a great like for LO).
Comment 32 Uwe Auer 2019-10-08 22:09:19 UTC
Created attachment 154848 [details]
Trace - Thread 6 UpdateCheckThread crashed

OP of question https://ask.libreoffice.org/en/question/212043/libreoffice-crashes-under-macos-mojave/ adds log file, which may be helpful to track down the issue. At least the log state that UpdateCheckThread (Thread 6) caused the crash.
Comment 33 divinerites 2019-10-17 10:41:50 UTC
- I can confirm this behaviour on MacOS 10.14.6 (for LO 6.2.7 and LO 6.3)
- I can confirm that disabling auto-update + reopen LO is a good workaround. No more crash.

I can't find the crash log on the Mac.
Comment 34 V Stuart Foote 2019-10-17 14:47:13 UTC
Looking at attachment 154848 [details] here, and attachment 154274 [details] and attachment 154240 [details] in dupe bug 127613 rather than cURL post used for checks on Windows, macOS build looks to use a neon-WebDav connection to check for updates.

The crash on macOS 10.12, 10.13, 10.14 occurs when attempting the OpenSSL cert verification. Reasonable to assume security patches from Apple would affect all.

So, is the issue then with our bundled neon package? We look to be several builds behind.
Comment 35 V Stuart Foote 2019-10-19 01:18:25 UTC
Crud, seems we are already on the latest neon-webdav 0.30.2 [1]

So is the libxsec_xmlsec lib setup for the nss3/nssutil3 connection being completed, how would one tell? But, if it is passing incorrect keyring data guess it might die horribly.

=-ref-=

[1] https://gerrit.libreoffice.org/#/c/44515/
Comment 36 Alex Thurgood 2019-10-24 06:20:12 UTC
*** Bug 128346 has been marked as a duplicate of this bug. ***
Comment 37 Andreas Piening 2019-10-24 15:02:42 UTC
I did a Bibisect based on the repo bibisect-mac64-6.1.
Here are the results:

edb6d291dd3e9c680e6c1d540796b729fe6f5975 is the first bad commit
commit edb6d291dd3e9c680e6c1d540796b729fe6f5975
Author: gerrit <gerrit@gerrits-Mini.home>
Date:   Thu Apr 19 19:36:19 2018 +0200

    source sha:ba69036c8e889237da4bb312d7c5c94066abbfd3

    source sha:ba69036c8e889237da4bb312d7c5c94066abbfd3

 LibreOffice.app/Contents/Resources/setuprc       |   2 +-
 LibreOffice.app/Contents/Resources/versionrc     |   4 ++--
 LibreOffice.app/Contents/bin/InfoPlist_en-US.zip | Bin 184 -> 184 bytes
 3 files changed, 3 insertions(+), 3 deletions(-)

With great help from Mike Kaganski in a ask.libreoffice.org thread (https://ask.libreoffice.org/en/question/213756/libreoffice-62-crashes-crashes-on-mac-os-catalina-after-a-while/) we found the commit that introduced this issue. It has the commit message "Upgrade update check and extension URLs to https" which most likely broke things.
Comment 38 V Stuart Foote 2019-10-24 15:30:38 UTC
https://gerrit.libreoffice.org/#/c/49237/
Comment 39 cla 2019-11-10 18:07:01 UTC
Just to confirm, the bug still persists in LibreOffice 6.3.3.2 on MacOS 10.13

The workaround still works 

If I start LO from the terminal I get this message "before" the crash
  (pkix_CacheCert_Add: PKIX_PL_HashTable_Add for Certs skipped: entry existed
Comment 40 Xisco Faulí 2019-12-02 13:40:07 UTC
Changing priority to 'highest' since this a regression and the number of duplicates is higher than 5 or the number of people in CC higher than 20
Comment 41 fxcoudert 2020-01-16 11:22:43 UTC
TL,DR: if you're a user affected by this, and have Homebrew installed, you can run `brew unlink nss` and it should go away. That is a work-around, and the LibreOffice issue should still be fixed, of course.

-------

It appears not everyone can reproduce this, and I think I know why: it may be related to the presence of Homebrew (https://brew.sh), and particularly Homebrew's install of the nss package: https://github.com/Homebrew/homebrew-core/issues/49058

The timing of this first bug report for this issue (2019-09-18) is shortly after Homebrew modified the way it installs nss (committed by me on 2019-09-07: https://github.com/Homebrew/homebrew-core/pull/43959). Before that date, we did not install the nss shared libraries in /usr/local/opt; now, we do:

$ ls /usr/local/lib/*nss*.dylib
/usr/local/lib/libevent_openssl-2.1.7.dylib
/usr/local/lib/libnssckbi-testlib.dylib
/usr/local/lib/libnssutil3.dylib
/usr/local/lib/libevent_openssl.dylib
/usr/local/lib/libnssckbi.dylib
/usr/local/lib/libnss3.dylib
/usr/local/lib/libnssdbm3.dylib

Most of Homebrew's software gets its libraries installed in /usr/local/lib, because it is useful for our users. The reason why nss previously was blacklisted from this is that it caused a crash in some Firefox extensions: https://bugzilla.mozilla.org/show_bug.cgi?id=1142646

I suspect that the issue is the same here: something in LibreOffice must be loading one of the nss shared libraries, in a way that LibreOffice's own copy is not loaded, but the /usr/local/lib version is loaded.

-------

To confirm that the bug is triggered by nss libraries in /usr/local/lib, I opened LibreOffice with nss installed, then triggered an update check => LibreOffice crashed (I'd like to provide the logs, but I do not know where they are).

Then, I ran `brew unlink nss` (which removes the nss libraries from /usr/local/lib). Starting LibreOffice again, I can now run an update check, and use the software with no crash.
Comment 42 fxcoudert 2020-01-16 11:32:45 UTC
Actually, the use who reported this to us (Homebrew) at https://github.com/Homebrew/homebrew-core/issues/49058 included a nice backtrace!

------------------------

$ /Applications/LibreOffice.app/Contents/MacOS/soffice --norestore --backtrace
(pkix_CacheCert_Add: PKIX_PL_HashTable_Add for Certs skipped: entry existed
Fatal exception: Signal 11
Stack:
/Applications/LibreOffice.app/Contents/Frameworks/libuno_sal.dylib.3+0x341e2(_ZN12_GLOBAL__N_110printStackEi+0x32)[0x108e771e2]
/Applications/LibreOffice.app/Contents/Frameworks/libuno_sal.dylib.3+0x340bc(_ZN12_GLOBAL__N_121signalHandlerFunctionEiP9__siginfoPv+0x2ec)[0x108e770bc]
/usr/lib/system/libsystem_platform.dylib+0x1f5a(_sigtramp+0x1a)[0x7fff56ec8f5a]
/usr/local/Cellar/nss/3.49/lib/libnssutil3.dylib+0x1f6d0(ucs2Utf8ConvertFunc+0xea8)[0x1afc7e6d0]
/usr/local/Cellar/nss/3.49/lib/libnssutil3.dylib+0xaeb8(SECOID_FindOID_Util+0x19)[0x1afc69eb8]
/usr/local/lib/libsmime3.dylib+0x11ebc(CERT_DecodeCertPackage+0x17c)[0x1afb30ebc]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0x14adcc(pkix_pl_HttpCertStore_DecodeCertPackage+0x1ec)[0x10c9e8dcc]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0x14b18d(pkix_pl_HttpCertStore_ProcessCertResponse+0x2ad)[0x10c9e918d]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0x144c53(pkix_pl_AIAMgr_GetHTTPCerts+0x783)[0x10c9e2c53]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0x145fb1(PKIX_PL_AIAMgr_GetAIACerts+0x431)[0x10c9e3fb1]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0xe71e8(pkix_BuildForwardDepthFirstSearch+0x9c8)[0x10c9851e8]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0xe4759(pkix_Build_InitiateBuildChain+0x1b89)[0x10c982759]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0xe2860(PKIX_BuildChain+0x180)[0x10c980860]
/Applications/LibreOffice.app/Contents/Frameworks/libnss3.dylib+0x1c236(CERT_PKIXVerifyCert+0x2a6)[0x10c8ba236]
/Applications/LibreOffice.app/Contents/Frameworks/libxsec_xmlsec.dylib+0x1b4d4(_ZN27SecurityEnvironment_NssImpl17verifyCertificateERKN3com3sun4star3uno9ReferenceINS2_8security12XCertificateEEERKNS3_8SequenceIS7_EE+0x404)[0x1b4d4f4d4]
/Applications/LibreOffice.app/Contents/Frameworks/libucpdav1.dylib+0x16675(_ZN10webdav_ucp11NeonSession19CertificationNotifyEPK20ne_ssl_certificate_s+0x3d5)[0x1b3ca1675]
/Applications/LibreOffice.app/Contents/Frameworks/libneon.dylib+0x12a7a(ne__negotiate_ssl+0x29a)[0x1b3d25a7a]
/Applications/LibreOffice.app/Contents/Frameworks/libneon.dylib+0xa5f6(send_request+0x496)[0x1b3d1d5f6]
/Applications/LibreOffice.app/Contents/Frameworks/libneon.dylib+0x9ac4(ne_begin_request+0xe4)[0x1b3d1cac4]
/Applications/LibreOffice.app/Contents/Frameworks/libneon.dylib+0xae18(ne_request_dispatch+0x28)[0x1b3d1de18]
/Applications/LibreOffice.app/Contents/Frameworks/libucpdav1.dylib+0x19670(_ZN10webdav_ucp11NeonSession7OPTIONSERKN3rtl8OUStringERNS_10DAVOptionsERKNS_21DAVRequestEnvironmentE+0x100)[0x1b3ca4670]
/Applications/LibreOffice.app/Contents/Frameworks/libucpdav1.dylib+0x77ba(_ZN10webdav_ucp17DAVResourceAccess7OPTIONSERNS_10DAVOptionsERKN3com3sun4star3uno9ReferenceINS5_3ucb19XCommandEnvironmentEEE+0x19a)[0x1b3c927ba]
/Applications/LibreOffice.app/Contents/Frameworks/libucpdav1.dylib+0x42353(_ZN10webdav_ucp7Content18getResourceOptionsERKN3com3sun4star3uno9ReferenceINS3_3ucb19XCommandEnvironmentEEERNS_10DAVOptionsERKNSt3__110unique_ptrINS_17DAVResourceAccessENSD_14default_deleteISF_EEEEPb+0xb3)[0x1b3ccd353]
/Applications/LibreOffice.app/Contents/Frameworks/libucpdav1.dylib+0x389a4(_ZN10webdav_ucp7Content4openERKN3com3sun4star3ucb20OpenCommandArgument3ERKNS3_3uno9ReferenceINS4_19XCommandEnvironmentEEE+0x734)[0x1b3cc39a4]
/Applications/LibreOffice.app/Contents/Frameworks/libucpdav1.dylib+0x2f49c(_ZN10webdav_ucp7Content7executeERKN3com3sun4star3ucb7CommandEiRKNS3_3uno9ReferenceINS4_19XCommandEnvironmentEEE+0xb0c)[0x1b3cba49c]
/Applications/LibreOffice.app/Contents/Frameworks/libucpdav1.dylib+0x3e5d2(_ZThn64_N10webdav_ucp7Content7executeERKN3com3sun4star3ucb7CommandEiRKNS3_3uno9ReferenceINS4_19XCommandEnvironmentEEE+0x12)[0x1b3cc95d2]
/Applications/LibreOffice.app/Contents/Frameworks/libupdatefeedlo.dylib+0x8460(_ZN12_GLOBAL__N_125UpdateInformationProvider4loadERKN3rtl8OUStringE+0x440)[0x1af99d460]
/Applications/LibreOffice.app/Contents/Frameworks/libupdatefeedlo.dylib+0x3d7e(ZN12_GLOBAL__N_125UpdateInformationProvider31getUpdateInformationEnumerationERKN3com3sun4star3uno8SequenceIN3rtl8OUStringEEERKS7+0xce)[0x1af998d7e]
/Applications/LibreOffice.app/Contents/Frameworks/libupdatefeedlo.dylib+0x5102(ZThn40_N12_GLOBAL__N_125UpdateInformationProvider31getUpdateInformationEnumerationERKN3com3sun4star3uno8SequenceIN3rtl8OUStringEEERKS7+0x12)[0x1af99a102]
/Applications/LibreOffice.app/Contents/Frameworks/libupdchklo.dylib+0x2a688(Z15checkForUpdatesR10UpdateInfoRKN3com3sun4star3uno9ReferenceINS4_17XComponentContextEEERKNS5_INS3_4task19XInteractionHandlerEEERKNS5_INS3_10deployment26XUpdateInformationProviderEEERKN3rtl8OUStringESN_RKNS4_8SequenceISL_EESN_SN+0xf8)[0x1b27f0688]
/Applications/LibreOffice.app/Contents/Frameworks/libupdchklo.dylib+0x2a409(_Z15checkForUpdatesR10UpdateInfoRKN3com3sun4star3uno9ReferenceINS4_17XComponentContextEEERKNS5_INS3_4task19XInteractionHandlerEEERKNS5_INS3_10deployment26XUpdateInformationProviderEEE+0x2b9)[0x1b27f0409]
/Applications/LibreOffice.app/Contents/Frameworks/libupdchklo.dylib+0xd6d6(_ZN12_GLOBAL__N_117UpdateCheckThread8runCheckERb+0x116)[0x1b27d36d6]
/Applications/LibreOffice.app/Contents/Frameworks/libupdchklo.dylib+0xd29c(_ZN12_GLOBAL__N_117UpdateCheckThread3runEv+0x19c)[0x1b27d329c]
/Applications/LibreOffice.app/Contents/Frameworks/libupdchklo.dylib+0xb49f(threadFunc+0xf)[0x1b27d149f]
/Applications/LibreOffice.app/Contents/Frameworks/libuno_sal.dylib.3+0x3726e(_ZL21osl_thread_start_ImplPv+0x7e)[0x108e7a26e]
/usr/lib/system/libsystem_pthread.dylib+0x3661(_pthread_body+0x154)[0x7fff56ed2661]
/usr/lib/system/libsystem_pthread.dylib+0x350d(_pthread_body+0x0)[0x7fff56ed250d]
/usr/lib/system/libsystem_pthread.dylib+0x2bf9(thread_start+0xd)[0x7fff56ed1bf9]
Abort trap: 6

------------------------

So LibreOffice's libnss3.dylib, in pkix_pl_HttpCertStore_DecodeCertPackage, is calling CERT_DecodeCertPackage from libsmime3.dylib, but this is loaded from from /usr/local/lib/libsmime3.dylib (if present) rather than LibreOffice's own libsmime3.dylib. This should be modified so that LibreOffice loads functions from its own libraries.
Comment 43 Commit Notification 2020-01-17 11:57:35 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

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

tdf#127619: external/nss: Load smime3 lib with a path on macOS

It will be available in 6.5.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.
Comment 44 Commit Notification 2020-01-18 19:25:03 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/5fd80277366bf3c41767981722e6cc316f858ead

tdf#127619: external/nss: Load smime3 lib with a path on macOS

It will be available in 6.3.5.

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.
Comment 45 Commit Notification 2020-01-19 00:00:19 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

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

tdf#127619: external/nss: Load smime3 lib with a path on macOS

It will be available in 6.4.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.
Comment 46 Commit Notification 2020-01-20 16:58:25 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-0":

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

tdf#127619: external/nss: Load smime3 lib with a path on macOS

It will be available in 6.4.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.
Comment 47 Matthew Hall 2020-01-23 00:31:46 UTC
Hi team,

Thanks for assisting with this fix for LibreOffice. I have zero experience testing experimental builds, because this is the first time in the entire time I have used it where I ran into a problem that a simple upgrade could not fix, despite some pretty technically demanding projects I have completed with the product.

Therefore I wanted to request some help understand how I should get the appropriate pre-release copy of the stable 6.3.x branch, where we are sure this fix is applied, so that I can verify that the issue is indeed fixed on my system, since I appear to be the person best equipped to do the verification at this time.

Matthew.
Comment 48 Stephan Bergmann 2020-01-24 12:42:02 UTC
(In reply to Matthew Hall from comment #47)
> Therefore I wanted to request some help understand how I should get the
> appropriate pre-release copy of the stable 6.3.x branch, where we are sure
> this fix is applied, so that I can verify that the issue is indeed fixed on
> my system, since I appear to be the person best equipped to do the
> verification at this time.

Ideally, <https://dev-builds.libreoffice.org/daily/> (reachable from the "Nightly Builds" section of <https://www.libreoffice.org/download/pre-releases/>) should provide regular builds of master and maybe even of libreoffice-6-3, for various platforms.  However, content appears to be rather sparse.
Comment 49 Matthew Hall 2020-01-28 17:53:51 UTC
I verified this with the following build, while Homebrew NSS was linked into place:

Version: 6.4.0.3
Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8

It appears to be functioning properly now, assuming that this build indeed included the fix.

It was a bit ambiguous, due to various date and time stamp considerations on the commits and the build itself.

Matthew.
Comment 50 Stephan Bergmann 2020-01-28 18:50:32 UTC
(In reply to Matthew Hall from comment #49)
> I verified this with the following build, while Homebrew NSS was linked into
> place:
> 
> Version: 6.4.0.3
> Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
> 
> It appears to be functioning properly now, assuming that this build indeed
> included the fix.

Yes, commit b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 (tag: libreoffice-6.4.0.3-buildfix1) includes commit fd29e95a02c6e1a92450b59d52c9d5cdf9f0eeb0 from comment 46.
Comment 51 Matthew Hall 2020-01-28 21:36:03 UTC
Thanks for fixing, and thanks again for confirming.

Matthew.