Download it now!
Bug 64672 - segmentation fault in XComponentLoader::loadComponentFromURL due to libvisio/libraptor/libxml2 interaction
Summary: segmentation fault in XComponentLoader::loadComponentFromURL due to libvisio/...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:4.2.0 target:4.1.0 target:3.6....
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-16 13:48 UTC by Horst Reiterer
Modified: 2016-09-19 16:47 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Dump archive (xz-based compression, split into 3kb parts) (2.93 MB, application/octet-stream)
2013-05-16 14:53 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:54 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:55 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:55 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:55 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:56 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:56 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:57 UTC, Horst Reiterer
Details
Dump archive (2.93 MB, application/octet-stream)
2013-05-16 14:58 UTC, Horst Reiterer
Details
Dump archive (506.91 KB, application/octet-stream)
2013-05-16 15:12 UTC, Horst Reiterer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Horst Reiterer 2013-05-16 13:48:10 UTC
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.
Comment 1 Horst Reiterer 2013-05-16 14:53:38 UTC
Created attachment 79422 [details]
Dump archive (xz-based compression, split into 3kb parts)
Comment 2 Horst Reiterer 2013-05-16 14:54:19 UTC
Created attachment 79423 [details]
Dump archive
Comment 3 Horst Reiterer 2013-05-16 14:55:15 UTC
Created attachment 79424 [details]
Dump archive
Comment 4 Horst Reiterer 2013-05-16 14:55:34 UTC
Created attachment 79425 [details]
Dump archive
Comment 5 Horst Reiterer 2013-05-16 14:55:55 UTC
Created attachment 79426 [details]
Dump archive
Comment 6 Horst Reiterer 2013-05-16 14:56:20 UTC
Created attachment 79427 [details]
Dump archive
Comment 7 Horst Reiterer 2013-05-16 14:56:45 UTC
Created attachment 79428 [details]
Dump archive
Comment 8 Horst Reiterer 2013-05-16 14:57:05 UTC
Created attachment 79429 [details]
Dump archive
Comment 9 Horst Reiterer 2013-05-16 14:58:19 UTC
Created attachment 79430 [details]
Dump archive
Comment 10 Horst Reiterer 2013-05-16 15:04:51 UTC
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.
Comment 11 Horst Reiterer 2013-05-16 15:12:21 UTC
Created attachment 79431 [details]
Dump archive
Comment 12 Julien Nabet 2013-05-17 19:39:33 UTC
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/)
Comment 13 Horst Reiterer 2013-06-26 15:05:10 UTC
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
Comment 14 Julien Nabet 2013-06-26 17:15:23 UTC
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?
Comment 15 Michael Stahl (CIB) 2013-06-26 20:55:26 UTC
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?)
Comment 16 Commit Notification 2013-06-26 21:01:06 UTC
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.
Comment 17 Michael Stahl (CIB) 2013-06-26 21:34:52 UTC
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.
Comment 18 Commit Notification 2013-06-26 21:56:52 UTC
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.
Comment 19 Commit Notification 2013-06-26 21:57:28 UTC
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.
Comment 20 Commit Notification 2013-06-26 21:57:50 UTC
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.
Comment 21 Commit Notification 2013-06-27 12:55:34 UTC
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.
Comment 22 Robinson Tryon (qubit) 2015-12-18 10:32:40 UTC Comment hidden (obsolete)
Comment 23 Xisco Faulí 2016-09-19 16:47:51 UTC Comment hidden (obsolete)