Download it now!
Bug 64962 - Crash with downgraded settings
Summary: Crash with downgraded settings
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.3.3 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0 target:4.1.0.0.beta2 tar...
Keywords:
Depends on:
Blocks: 43489
  Show dependency treegraph
 
Reported: 2013-05-24 16:57 UTC by Michael Meeks
Modified: 2013-06-05 12:33 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2013-05-24 16:57:23 UTC
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.
Comment 1 Stephan Bergmann 2013-05-27 06:55:32 UTC
@mmeeks: can you reproduce it?
Comment 2 Michael Meeks 2013-05-27 08:27:30 UTC
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 ...
Comment 3 Stephan Bergmann 2013-05-27 08:32:04 UTC
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
Comment 4 Michael Meeks 2013-06-05 10:33:31 UTC
> 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 ].
Comment 5 Stephan Bergmann 2013-06-05 11:40:59 UTC
(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.
Comment 6 Michael Meeks 2013-06-05 12:06:10 UTC
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 :-)
Comment 7 Commit Notification 2013-06-05 12:12:13 UTC
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.
Comment 8 Commit Notification 2013-06-05 12:20:22 UTC
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.
Comment 9 Commit Notification 2013-06-05 12:33:52 UTC
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.