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

- Other *NIX (https://www.linuxquestions.org/questions/other-%2Anix-55/)

- - OpenOffice on OS/X now consistently dies about thirty seconds after you start it ... (https://www.linuxquestions.org/questions/other-%2Anix-55/openoffice-on-os-x-now-consistently-dies-about-thirty-seconds-after-you-start-it-4175715359/)

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

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?

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

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.

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.

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

Thanks for reporting back - interesting 'feature'. :D

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!"