Since the update from 3.5.4 to 4.0.0 (build user: 4.0.0.3-103), the LibreOffice process randomly terminates with a segmentation fault in XComponentLoader::loadComponentFromURL. We're using UNO to control the LibreOffice process. The issues does not seem to be connected to a specific input. To be more specific, we do not have any Visio input. The stack trace (without LibreOffice symbols) is as follows: #0 0x00007f47627a581c in librdf_parser_raptor_error_handler (data=<value optimized out>, locator=0x7f47545245f8, message=0x7f47547f3b20 "XML parser error: Document is empty") at rdf_parser_raptor.c:364 #1 0x00007f47622fec44 in raptor_log_error () from /opt/libreoffice4.0/program/../program/libraptor-lo.so.1 #2 0x00007f47623087ef in raptor_libxml_xmlStructuredErrorFunc () from /opt/libreoffice4.0/program/../program/libraptor-lo.so.1 #3 0x00007f478267eca9 in __xmlRaiseError () from /opt/libreoffice4.0/program/../ure-link/lib/libxml2.so.2 #4 0x00007f47826836ee in xmlFatalErr () from /opt/libreoffice4.0/program/../ure-link/lib/libxml2.so.2 #5 0x00007f4782695522 in xmlParseTryOrFinish () from /opt/libreoffice4.0/program/../ure-link/lib/libxml2.so.2 #6 0x00007f4782696ad9 in xmlParseChunk__internal_alias () from /opt/libreoffice4.0/program/../ure-link/lib/libxml2.so.2 #7 0x00007f4782724608 in xmlTextReaderPushData () from /opt/libreoffice4.0/program/../ure-link/lib/libxml2.so.2 #8 0x00007f47827250e7 in xmlTextReaderRead__internal_alias () from /opt/libreoffice4.0/program/../ure-link/lib/libxml2.so.2 #9 0x00007f47616c5a8d in (anonymous namespace)::isXmlVisioDocument(WPXInputStream*) () from /opt/libreoffice4.0/program/../program/libwpftdrawlo.so #10 0x00007f47616c6485 in libvisio::VisioDocument::isSupported(WPXInputStream*) () from /opt/libreoffice4.0/program/../program/libwpftdrawlo.so #11 0x00007f4761684027 in VisioImportFilter::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&) () from /opt/libreoffice4.0/program/../program/libwpftdrawlo.so #12 0x00007f476c1727e0 in filter::config::TypeDetection::impl_askDetectService(rtl::OUString const&, comphelper::MediaDescriptor&) () from /opt/libreoffice4.0/program/../program/libfilterconfiglo.so #13 0x00007f476c172f34 in filter::config::TypeDetection::impl_detectTypeDeepOnly(comphelper::MediaDescriptor&, comphelper::SequenceAsVector<rtl::OUString> const&) () from /opt/libreoffice4.0/program/../program/libfilterconfiglo.so #14 0x00007f476c174818 in filter::config::TypeDetection::queryTypeByDescriptor(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, unsigned char) () from /opt/libreoffice4.0/program/../program/libfilterconfiglo.so #15 0x00007f476e977e42 in framework::LoadEnv::impl_detectTypeAndFilter() () from /opt/libreoffice4.0/program/../program/libfwklo.so #16 0x00007f476e97fde4 in framework::LoadEnv::startLoading() () from /opt/libreoffice4.0/program/../program/libfwklo.so #17 0x00007f476e980030 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /opt/libreoffice4.0/program/../program/libfwklo.so #18 0x00007f476e9b5ed0 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /opt/libreoffice4.0/program/../program/libfwklo.so #19 0x00007f4776b76b90 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, unsigned int, double*, unsigned int) () from /opt/libreoffice4.0/ure/lib/libgcc3_uno.so #20 0x00007f4776b7a630 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) () from /opt/libreoffice4.0/ure/lib/libgcc3_uno.so #21 0x00007f4776b7b1da in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) () from /opt/libreoffice4.0/ure/lib/libgcc3_uno.so #22 0x00007f476f9c36ef in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const () from /opt/libreoffice4.0/ure/lib/binaryurp.uno.so #23 0x00007f476f9c418e in binaryurp::IncomingRequest::execute() const () from /opt/libreoffice4.0/ure/lib/binaryurp.uno.so #24 0x00007f476f9c8c26 in request () from /opt/libreoffice4.0/ure/lib/binaryurp.uno.so #25 0x00007f478612de23 in cppu_threadpool::JobQueue::enter(long, unsigned char) () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_cppu.so.3 #26 0x00007f478612f10e in cppu_threadpool::ORequestThread::run() () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_cppu.so.3 #27 0x00007f478612f5aa in threadFunc () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_cppu.so.3 #28 0x00007f4786cc934d in osl_thread_start_Impl () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_sal.so.3 #29 0x000000300c807851 in start_thread () from /lib64/libpthread.so.0 #30 0x000000300c0e767d in clone () from /lib64/libc.so.6 I cannot reproduce the issue outside of our software at this point.
Created attachment 79422 [details] Dump archive (xz-based compression, split into 3kb parts)
Created attachment 79423 [details] Dump archive
Created attachment 79424 [details] Dump archive
Created attachment 79425 [details] Dump archive
Created attachment 79426 [details] Dump archive
Created attachment 79427 [details] Dump archive
Created attachment 79428 [details] Dump archive
Created attachment 79429 [details] Dump archive
Created attachment 79430 [details] Dump archive
I added a dump representing the segmentation fault (download all "Dump archive" attachments). The dump can be opened as follows: cat libreoffice-dump.tar.xz_* | xz -d > libreoffice-dump.tar tar xf libreoffice-dump.tar cd libreoffice-dump gdb -ex "set solib-absolute-prefix ." -ex "core core.17796" /opt/libreoffice4.0/program/soffice.bin LibreOffice build 4.0.0.3-103 must be installed.
Created attachment 79431 [details] Dump archive
I know that LO uses a newer version of raptor in master branch. (see http://cgit.freedesktop.org/libreoffice/core/commit/?id=d719c01c2f112d97b09aee008f9bfee57719eeed) For the test, could you give a try to a daily build? (see http://dev-builds.libreoffice.org/daily/)
Thanks for the input! I tested the issue with the daily build (4.2.0.0.alpha0-2013-06-26_00.15.36) and cannot reproduce the segmentation fault within a timeframe that usually results in an abort. After switching back to 4.0, the segmentation fault occurred again within a matter of minutes. When will the next release (4.1?) with the new version of raptor (libraptor2-lo.so.0) be available? Any chance for a backport to 4.0? Test results: OK: LibreOffice 3.6.6.2/libraptor-lo.so.1 LibreOffice 4.1.0.1/libraptor2-lo.so.0 LibreOffice 4.2.0.0.alpha0-2013-06-26_00.15.36/libraptor2-lo.so.0 NOK: LibreOffice 4.0.0.3/libraptor-lo.so.1 LibreOffice 4.0.4.2/libraptor-lo.so.1
Horst: thank you for your feedback. About 4.1 branch, it should be ok for 4.1.0 and this one should be released at the end of July (see https://wiki.documentfoundation.org/ReleasePlan#4.1_release). About 4.0 backport, see below. Michael: is it ok if I cherry pick the commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=d719c01c2f112d97b09aee008f9bfee57719eeed and submit it for review on gerrit for 4.0 branch?
no the new raptor can't be backported easily as the 4.0 branch has to run on Mac OS 10.4 and the libxml2 on that is too old... but honestly i'm surprised that this serious bug in raptor (another instance of messing with libxml2 global state) is only found now, after shipping this thing for 5 years... _perhaps_ we've never had an import filter that uses libxml2 in type-detection until the new libvisio started to read XML-based Visio files? (and everything else that uses libxml2 doesn't get to read invalid input so doesn't call error handlers?)
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=246a78b1d2a88ff1937b09b22325d160739ef47e fdo#64672 prevent raptor from setting global libxml2 error handlers 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.
reading the raptor code it's not at all clear to me why it should not crash with the newer version in LO 4.1: it also sets the global error handlers by default... but at least now there is a way to disable that. so for master/4.1 only disabling some feature flags when creating the librdf_world is needed. for 4.0 the same is needed (for a --with-system-redland build) and in addition a patch to the bundled old raptor lib; patches are in gerrit.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae11e5501c9cf436a3f8b956e9b3fba6d1cb67cf&h=libreoffice-4-1 fdo#64672 prevent raptor from setting global libxml2 error handlers 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 Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9727a88b614350c832c151fbc670097850cdcc97&h=libreoffice-4-0 fdo#64672 prevent raptor from setting global libxml2 error handlers 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=402a919c54bca942941e8ef2f0b340047fa152fc&h=libreoffice-4-0 fdo#64672 prevent raptor from setting global libxml2 error handlers 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c1559ba0ba71bb18faacd18016cd9e3b510c598&h=libreoffice-4-0 fdo#64672: untested attempt to get unordf to link in raptor with MSVC 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.
Migrating Whiteboard tags to Keywords: (Need_Advice -> needAdvice) [NinjaEdit]
'needsConfirmationAdvice' is only used for unconfirmed bugs. Removing it from this bug. [NinjaEdit]