Created attachment 78888 [details] File that crashes LibreOffice for me I've attached a ".docx" document. If I open this document in LibreOffice 4.0.2.2, then it closes immediately (crash). I only tried this on ArchLinux, so I'm unsure if all distributions are affected. I kept Severity at "normal". Please increase if this bug can be reproduced by developers.
no crash but "I/O error" message if I try opening the attached file with LibO 4.0.2.2 using Windows Vista 64bit. setting status to NEW and platform to ALL.
No crash with 3.5.4.2, But it crashes in latest development build.
Created attachment 78890 [details] backtrace for master (LO 4.1.0.0.alpha0+) Crashes for me to under Ubuntu 12.04 x86-64 with current master (Version: 4.1.0.0.alpha0+ Build ID: 19fe3be985a0d13c9818f920cb8e540ff658425) backtrace attached. Best regards. JBF
Reproduce on linux with master. n_th@tpa10 /lo/core $ /lo/core/install/program/soffice ~/03_AB_Lineare_Funktionen_Geradenbu?schel.docx warn:configmgr:19743:1:configmgr/source/xcuparser.cxx:713: unknown property "CurrentTempURL" in "file:///home/n_th/.config/libreoffice/4/user/registrymodifications.xcu" Exited with code '81' oosplash: re-start with all params ! warn:legacy.osl:19751:1:oox/source/docprop/docprophandler.cxx:320: For now unexpected tags are ignored! warn:legacy.osl:19751:1:oox/source/docprop/docprophandler.cxx:320: For now unexpected tags are ignored! warn:legacy.osl:19751:1:oox/source/docprop/docprophandler.cxx:320: For now unexpected tags are ignored! warn:legacy.osl:19751:1:oox/source/docprop/docprophandler.cxx:320: For now unexpected tags are ignored! warn:legacy.osl:19751:1:oox/source/docprop/docprophandler.cxx:320: For now unexpected tags are ignored! warn:legacy.osl:19751:1:oox/source/helper/graphichelper.cxx:121: GraphicHelper::GraphicHelper - cannot get target frame warn:legacy.osl:19751:1:oox/source/helper/graphichelper.cxx:121: GraphicHelper::GraphicHelper - cannot get target frame warn:writerfilter:19751:1:writerfilter/source/dmapper/GraphicImport.cxx:1563: failed. Message :GraphicCrop warn:oox:19751:1:oox/source/helper/propertyset.cxx:139: PropertySet::implSetPropertyValue - cannot set property "LineJoint" warn:writerfilter:19751:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:1715: Exception when adding shape: warn:writerfilter:19751:1:writerfilter/source/dmapper/OLEHandler.cxx:114: Exception in OLE Handler: position cannot be determined with this method warn:oox:19751:1:oox/source/helper/propertyset.cxx:139: PropertySet::implSetPropertyValue - cannot set property "LineJoint" warn:writerfilter:19751:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:1715: Exception when adding shape: warn:sw.uno:19751:1:sw/source/core/unocore/unotext.cxx:2290: Exception when setting property: HorizontalBorder. Message: warn:sw.uno:19751:1:sw/source/core/unocore/unotext.cxx:2290: Exception when setting property: VerticalBorder. Message: warn:sw.uno:19751:1:sw/source/core/unocore/unotext.cxx:2290: Exception when setting property: BottomBorder. Message: warn:sw.uno:19751:1:sw/source/core/unocore/unotext.cxx:2290: Exception when setting property: LeftBorder. Message: warn:sw.uno:19751:1:sw/source/core/unocore/unotext.cxx:2290: Exception when setting property: RightBorder. Message: warn:sw.uno:19751:1:sw/source/core/unocore/unotext.cxx:2290: Exception when setting property: TopBorder. Message: warn:writerfilter:19751:1:writerfilter/source/dmapper/OLEHandler.cxx:114: Exception in OLE Handler: position cannot be determined with this method Exited with code '139' the problem seems to be with d4fd86e3a48defbff29bfbabfbf0d2c5d95d39f5 the the patch above the appendTableManager() call is not done because of the exception... but latter we still popTableManager(); and that is how we end up with en empty stack taht trigger the segfault seen in the backtrace included by Jean Baptiste. PS: I always wonder what exception were for, and how they worked... well, they do not because they can't magically make all the changes in the try block 'atomic'... so here we pushed an object in one stack and execption out before we did the other thing that was expected... and the return trip assume everything is ok because of the first push.... the following patch seems to work around the problem, no idea if it is 'correct', since I have no idea what the code actually does... n_th@tpa10 /lo/core $ git diff diff --git a/writerfilter/source/dmapper/DomainMapper_Impl.cxx b/writerfilter/source/dmapper/DomainMapper_Impl.cxx index b5a5baa..2efc636 100644 --- a/writerfilter/source/dmapper/DomainMapper_Impl.cxx +++ b/writerfilter/source/dmapper/DomainMapper_Impl.cxx @@ -1647,6 +1647,8 @@ void DomainMapper_Impl::PushShapeContext( const uno::Reference< drawing::XShape if (m_aTextAppendStack.empty()) return; uno::Reference<text::XTextAppend> xTextAppend = m_aTextAppendStack.top().xTextAppend; + appendTableManager( ); + appendTableHandler( ); try { uno::Reference< lang::XServiceInfo > xSInfo( xShape, uno::UNO_QUERY_THROW ); @@ -1705,15 +1707,12 @@ void DomainMapper_Impl::PushShapeContext( const uno::Reference< drawing::XShape xProps->setPropertyValue( rPropNameSupplier.GetName( PROP_ANCHOR_TYPE ), bIsGraphic ? uno::makeAny( text::TextContentAnchorType_AS_CHARACTER ) : uno::makeAny( text::TextContentAnchorType_AT_PARAGRAPH ) ); } } - - appendTableManager( ); - appendTableHandler( ); - getTableManager().startLevel(); } catch ( const uno::Exception& e ) { SAL_WARN("writerfilter", "Exception when adding shape: " << e.Message); } + getTableManager().startLevel(); }
Indeed, this patch fix the crash for me on Version: 4.1.0.0.alpha0+ Build ID: af2e63c10cd34ef4eae898e463951682abf630c Thank you very much. Best regards. JBF
should we mark as FIXED or wait for other confirmations? Fix in the 4.1 alpha could be safely backported to LibO 4.0.4 or not? (too late to be included in 4.0.3)
@tommy: it is not 'fixed' yet... you want to set FIXED only once the patch land in git.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ceda3013a6b7e60e0e56ba540e217fd36a34a0f fdo#64249: make sure we have matching start/end level for table in shapes 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.
fixed in master branch. Pending for libreoffice-4-0. @Norbert: I tweaked a bit your patch to make sure we don't fall into weird cases again.
*** Bug 64424 has been marked as a duplicate of this bug. ***
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=df73fa5feb10df10c4ba036be5fac1ddb9b6915f&h=libreoffice-4-0 fdo#64249: make sure we have matching start/end level for table in shapes It will be available in LibreOffice 4.0.4. 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.