This is rather thrilling ;-) I managed to get the horror / exception crash where we bomb out with: terminate called after throwing an instance of 'com::sun::star::lang::WrappedTargetRuntimeException' Program received signal SIGABRT, Aborted. While just using the app (well Calc really). That I suspect is related to bug#62155 etc. I strongly suspect Java is involved - since I couldn't reproduce it at all unless I ran soffice --backtrace # ie. had javaldx setup etc. [ annoying there is no soffice --gdb to use which is a shame ]. The trace is: Thread 7 (Thread 0xad6ffb40 (LWP 26581)): #0 0xb7c66245 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0xb7c67ac3 in __GI_abort () at abort.c:90 #2 0xb7e6428d in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 #3 0xb7e61ef3 in __cxxabiv1::__terminate (handler=0xb7e64140 <__gnu_cxx::__verbose_terminate_handler()>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:40 #4 0xb7e61f2f in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:50 #5 0xb7e62225 in __cxxabiv1::__cxa_rethrow () at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:116 #6 0xaa2873a6 in dp_manager::ExtensionManager::getAllExtensions(com::sun::star::uno::Reference<com::sun::star::task::XAbortChannel> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) () from /opt/libreoffice4.0/program/../program/libdeployment.so #7 0xaa28e452 in dp_info::PackageInformationProvider::getExtensionList() () from /opt/libreoffice4.0/program/../program/libdeployment.so #8 0xad89972f in checkForPendingUpdates(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) () from /opt/libreoffice4.0/program/../program/libupdchk.so #9 0xad87b2fb in UpdateCheck::initialize(com::sun::star::uno::Sequence<com::sun::star::beans::NamedValue> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) () from /opt/libreoffice4.0/program/../program/libupdchk.so #10 0xad887de0 in (anonymous namespace)::InitUpdateCheckJobThread::run() () from /opt/libreoffice4.0/program/../program/libupdchk.so #11 0xad87c25e in threadFunc () from /opt/libreoffice4.0/program/../program/libupdchk.so #12 0xb7fa2fa9 in osl_thread_start_Impl () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_sal.so.3 ---Type <return> to continue, or q <return> to quit--- #13 0xb7c23b5e in start_thread (arg=0xad6ffb40) at pthread_create.c:308 #14 0xb7d1616e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131 Which is rather unfortunate ;-) It happens as the update check is triggered at a semi-random time (it seems); but after a short wait & a bit of clicking / text editing ... it's there. Main thread is quiescent.
@mmeeks: can you reproduce it?
I used to be able to ;-) No idea how to trigger that but I guess it's a matter of waiting until this is done: void SAL_CALL InitUpdateCheckJobThread::run() { if (!m_bShowDialog) { TimeValue tv = { 25, 0 }; m_aCondition.wait( &tv ); if ( m_bTerminating ) return; } I imagine you'd want to know where the exception comes from - but this is for a release build, so I'd be unlikely to get a good stack-trace ...
stick a catch(css::uno::Exception&e){SAL_DEBUG("caught <"<<e.Message<<">");throw;} into dp_manager::ExtensionManager::getAllExtensions to help track down what that WrappedTargetRuntimeException is about
> stick a > catch(css::uno::Exception&e){SAL_DEBUG("caught <"<<e.Message<<">");throw;} > into dp_manager::ExtensionManager::getAllExtensions to help track down what > that WrappedTargetRuntimeException is about I could only reproduce this in a system-installed build with no debuginfo. Sadly now I can't reproduce it anymore - which is profoundly frustrating. Possibly I was having DNS / connectivity hiccups at the time (if that helps) - though why we should do any networking during getAllExtensions is unclear to me. Hmm. I would -dearly- love to have these un-caught extensions caught and printed out un-conditionally, in shipping builds at the top-level to help debug this stuff; did we decide not to do that for some reason ? [ we do on Android IIRC ].
(In reply to comment #4) > I would -dearly- love to have these un-caught extensions caught and printed > out un-conditionally, in shipping builds at the top-level to help debug this > stuff; did we decide not to do that for some reason ? [ we do on Android > IIRC ]. Note that this is from a non-main thread, so generic catching of css::uno::Exception to print its Message would need to go into osl_thread_start_Impl, but that's too low-level to know css::uno::Exception. The best approach would be if css::uno::Exception inherited from std::exception and would use its what() for Message, so that GCC's __gnu_cxx::__verbose_terminate_handler would print it out along with the exception's type. But that would be an incompatible change.
Would love to go deeper, but - it seems that the updatecheck.cxx catches and discards all exceptions silently from similar code, so updated updatecheckjob.cxx to do the same: no point in killing the whole suite if we can't connect to the update server :-) Not a satisfying fix, I'm still ~certain there is some twisty badness in the extension registration / querying logic - but ... can't find it :-)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=05e2d2bf036e690f139d480d28929845ecfe136b fdo#64962 - ignore exceptions from checking with the update service. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9d1360a371f7335f1ede2f9ffe6f0282c53a07e7&h=libreoffice-4-1 fdo#64962 - ignore exceptions from checking with the update service. It will be available in LibreOffice 4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e5c8d34ed480c62455e24347a5858ea3b84d48c&h=libreoffice-4-0 fdo#64962 - ignore exceptions from checking with the update service. It will be available in LibreOffice 4.0.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.