[SOLVED] OpenOffice on OS/X now consistently dies about thirty seconds after you start it ...

sundialsvcs · 08-04-2022, 09:16 AM

This just started recently happening on my OS/X box: the latest version of OpenOffice, with the latest version of the Java JRE installed, very consistently crashes crashes about thirty seconds after it has been started – even if you do absolutely nothing. (Just start the program and wait. Don't do anything.) It's always about the same amount of "survival time."

I have not thoroughly investigated this matter yet, but I'd be curious to know if this sort of issue has lately been happening in any other contexts, such as Linux.

For many years, OpenOffice has been nothing but rock-solid, and so I really don't know what has disrupted it now. Especially, "in this way." (Again: "don't 'do' anything.") Which, to me, is very unusual ...

(Of course, I've tried things like "discarding preferences files.") This began happening just a few weeks ago and right now I really can't tie it to any particular contemporary change. Before I knuckle-down to try to actually debug this thing, "is any of it familiar?" Any vendor problem-reports I should look at?

fatmac · 08-05-2022, 04:44 AM

Maybe a dodgy/dying ram chip, warms up & throws a wobbly(?) - I think I'd check that first.

DarrenDrapkin · 08-05-2022, 10:13 AM

I am a long term user of open office. I am using slackware64 15.0 on a sony vaio. I do not have this problem. Making two votes for dogy hardware on your system.

sundialsvcs · 08-07-2022, 01:12 PM

Since I have several independent user-ids on this system, I have determined that the problem does not occur on any of the other ones.

After having (by the command-line) purged all files and directories which resemble "*ffice*" and "*acle*" for this user, I remain puzzled. Examination of system logs, even as an Administrator user, shows nothing.

However, I now know that the application is failing because of something that is particular to this user, although I have not yet identified it, nor found the application failure-log.

sundialsvcs · 08-22-2022, 03:07 PM

I finally discovered a root-owned directory, ~/Library/Logs/DiagnosticReports (notice: in my home directory), which contained the clue which finally enabled me to solve this. (After I used godly powers to chown it ... I have no idea why it didn't belong to me.)

The crash turned out to be related to "automatically check for updates." When I turned this option off, the problem went away. Of course, I promptly reported it to their version of BugZilla ...

Code:

Thread 5 Crashed:
0   libplds4.dylib                	       0x16859d0a5 PL_HashTableLookupConst + 16
1   libnssutil3.dylib             	       0x168a273da SECOID_FindOID_Util + 25
2   libsmime3.dylib               	       0x1688c95b0 CERT_DecodeCertPackage + 335
3   libnss3.dylib                 	       0x168ed7b40 0x168e14000 + 801600
4   libnss3.dylib                 	       0x168ed7de3 0x168e14000 + 802275
5   libnss3.dylib                 	       0x168ed3ed0 0x168e14000 + 786128
6   libnss3.dylib                 	       0x168ed4cca 0x168e14000 + 789706
7   libnss3.dylib                 	       0x168ea0ef0 0x168e14000 + 577264
8   libnss3.dylib                 	       0x168e9f631 0x168e14000 + 570929
9   libnss3.dylib                 	       0x168e9d9f4 0x168e14000 + 563700
10  libnss3.dylib                 	       0x168e24b8d CERT_PKIXVerifyCert + 1437
11  libxsec_xmlsec.dylib          	       0x1689ba337 SecurityEnvironment_NssImpl::verifyCertificate(com::sun::star::uno::Reference<com::sun::star::security::XCertificate> const&, com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::security::XCertificate> > const&) + 1735
12  libucpdav1.dylib              	       0x1687bbece http_dav_ucp::SerfSession::verifySerfCertificateChain(int, serf_ssl_certificate_t const* const*, int) + 2398
13  libserf-1.dylib               	       0x168aabf2a 0x168aa4000 + 32554
14  libserf-1.dylib               	       0x168bcaed6 X509_verify_cert + 2262
15  libserf-1.dylib               	       0x168adf6dc ssl_verify_cert_chain + 444
16  libserf-1.dylib               	       0x168ab8f60 ssl3_get_server_certificate + 368
17  libserf-1.dylib               	       0x168ab7d9f ssl3_connect + 2319
18  libserf-1.dylib               	       0x168ac7f1c ssl23_connect + 3100
19  libserf-1.dylib               	       0x168ac826f ssl23_read + 79
20  libserf-1.dylib               	       0x168aac801 0x168aa4000 + 34817
21  libserf-1.dylib               	       0x168aa66ef serf_databuf_peek + 79
22  libserf-1.dylib               	       0x168aae885 serf__process_connection + 309
23  libserf-1.dylib               	       0x168aa5e24 serf_event_trigger + 180
24  libserf-1.dylib               	       0x168aa5f09 serf_context_run + 185
25  libucpdav1.dylib              	       0x1687b4110 http_dav_ucp::SerfRequestProcessor::runProcessor() + 112
26  libucpdav1.dylib              	       0x1687b4316 http_dav_ucp::SerfRequestProcessor::processGet(com::sun::star::uno::Reference<http_dav_ucp::SerfInputStream> const&, std::__1::vector<rtl::OUString, std::__1::allocator<rtl::OUString> > const&, http_dav_ucp::DAVResource&, int&) + 54
27  libucpdav1.dylib              	       0x1687befd7 http_dav_ucp::SerfSession::GET(rtl::OUString const&, std::__1::vector<rtl::OUString, std::__1::allocator<rtl::OUString> > const&, http_dav_ucp::DAVResource&, http_dav_ucp::DAVRequestEnvironment const&) + 263
28  libucpdav1.dylib              	       0x1687a288a http_dav_ucp::DAVResourceAccess::GET(std::__1::vector<rtl::OUString, std::__1::allocator<rtl::OUString> > const&, http_dav_ucp::DAVResource&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) + 458
29  libucpdav1.dylib              	       0x168788933 http_dav_ucp::Content::open(com::sun::star::ucb::OpenCommandArgument2 const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) + 1763
30  libucpdav1.dylib              	       0x16877f6fa http_dav_ucp::Content::execute(com::sun::star::ucb::Command const&, int, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) + 2714
31  libucpdav1.dylib              	       0x16878e082 non-virtual thunk to http_dav_ucp::Content::execute(com::sun::star::ucb::Command const&, int, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) + 18
32  updatefeed.uno.dylib          	       0x1683ff667 0x1683fa000 + 22119
33  updatefeed.uno.dylib          	       0x1683fea4e 0x1683fa000 + 19022
34  updatefeed.uno.dylib          	       0x1683ff152 0x1683fa000 + 20818
35  updchk.uno.dylib              	       0x11a5a8b24 checkForUpdates(UpdateInfo&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::task::XInteractionHandler> const&, com::sun::star::uno::Reference<com::sun::star::deployment::XUpdateInformationProvider> const&) + 1460
36  updchk.uno.dylib              	       0x11a59de00 0x11a595000 + 36352
37  updchk.uno.dylib              	       0x11a59db1f 0x11a595000 + 35615
38  libsofficeapp.dylib           	       0x10f46d5cf threadFunc + 15
39  libuno_sal.dylib.3            	       0x10f56e855 0x10f568000 + 26709
40  libsystem_pthread.dylib       	    0x7ff80c9064e1 _pthread_start + 125
41  libsystem_pthread.dylib       	    0x7ff80c901f6b thread_start + 15

fatmac · 08-23-2022, 05:13 AM

Thanks for reporting back - interesting 'feature'.

sundialsvcs · 08-26-2022, 12:11 PM

I guess the programmers forgot the mantra of "always wrap things in a try ... catch block!"

When the check-for-update logic threw an exception, it was never caught, so it busted out the top and blew the whole program very-ungraciously out of the water.

Of course what I should have seen is a nice dialog-box which says, "Oops, the check for automatic updates unexpectedly failed due to a runtime error. [OK]" Like any sensible piece of professional software would do. I immediately reported the problem to their Bugzilla with a comment to that effect. I really don't know how they missed this. "Things can go wrong!"