Created attachment 78780 [details] reproduction case Reproduction instructions ========================= Open attachment "reproduction case" Observed behaviour ================== segfault/crash/exit with return value 139 (128+11, where 11 == SIGSEGV). Expected behaviour ================== Show document Tested versions =============== Debian x86-64 Debian-provided package 1:3.5.4+dfsg-4: segfault Debian x86-64 TDF official build 3.6.3.2: segfault Debian x86-64 my own libreoffice-4-0 dev tree: segfault Debian x86-64 TDF official build 4.0.3.1: segfault BUT Debian x86-64 TDF official build 3.4.6: no segfault, document opens correctly Background information ====================== That document is generated by Base Report builder (in my dev tree, after a few other reportbuilder "problems" are solved, or by LibreOffice 3.4). This crash is blocking my current task of "fix charts in report builder (b0rken since LibreOffice 3.5)", which is why I'd appreciate if it was treated with somewhat higher priority. Thanks in advance! Analysis ======== Segfault happens in editeng/source/items/frmitems.cxx, function SvxBoxItem::PutValue (gdb) frame #12 0x00007fb84eeb5f2c in SvxBoxItem::PutValue (this=0x3d94590, rVal=uno::Any 0, nMemberId=15 '\017') at /home/master/src/libreoffice/workdirs/libreoffice-4.0/editeng/source/items/frmitems.cxx:1969 In: case LINE_WIDTH: { // Set the line width on all borders long nWidth(0); rVal >>= nWidth; if( bConvert ) nWidth = MM100_TO_TWIP( nWidth ); // Set the line Width on all borders const sal_uInt16 aBorders[] = { BOX_LINE_LEFT, BOX_LINE_RIGHT, BOX_LINE_BOTTOM, BOX_LINE_TOP }; for (int n(0); n != SAL_N_ELEMENTS(aBorders); ++n) { editeng::SvxBorderLine* pLine = const_cast< editeng::SvxBorderLine* >( GetLine( aBorders[n] ) ); pLine->SetWidth( nWidth ); } } with n==0, hence aBorders[n]==BOX_LINE_LEFT, hence GetLine( aBorders[n] ) == this->pLeft == 0x0, hence segfault. All four of pLeft, pRight, pBottom and pTop are NULL. Not initialised? I'm not sure if this should just do: if( pLeft == NULL) pLeft = new SvxBorderLine; or if this is a symptom of a deeper problem. Higher up in the callstack: #14 0x00007fb83d38202e in SwXFrame::setPropertyValue (this=0x3d94430, rPropertyName="LineWidth", aValue=uno::Any 0) at /home/master/src/libreoffice/workdirs/libreoffice-4.0/sw/source/core/unocore/unoframe.cxx:1310 #15 0x00007fb8538d09d1 in SvXMLImportPropertyMapper::_FillPropertySet #17 0x00007fb85370cfcd in XMLShapeStyleContext::FillPropertySet #18 0x00007fb8539528e8 in XMLTextFrameContext_Impl::Create #19 0x00007fb853955156 in XMLTextFrameContext_Impl::XMLTextFrameContext_Impl #20 0x00007fb853957c08 in XMLTextFrameContext::CreateChildContext #21 0x00007fb8536ed1e3 in SvXMLImport::startElement(this=0x44db2e0, rName="draw:object-ole", ...) In particular, frame 15, we are in the loop "// iterate over property states that we want to set" and i==69 (gdb) print rProperties[i] $84 = (__alloc_traits<std::allocator<XMLPropertyState> >::value_type &) @0x3fae6c0: { mnIndex = 3, maValue = uno::Any 0 } (gdb) print rProperties $85 = std::__debug::vector of length 84, capacity 128 = {{ mnIndex = 46, maValue = uno::Any 0 }, { mnIndex = 211, maValue = uno::Any 0 }, { mnIndex = 47, maValue = uno::Any 0 }, { mnIndex = 212, maValue = uno::Any 0 }, { mnIndex = 40, maValue = uno::Any 0 }, { mnIndex = 44, maValue = uno::Any 0 }, { mnIndex = 213, maValue = uno::Any 0 }, { mnIndex = 51, maValue = uno::Any 0 '\000' }, { mnIndex = 41, maValue = uno::Any 0 }, { mnIndex = 43, maValue = uno::Any 0 }, { mnIndex = 161, maValue = uno::Any 0 }, { mnIndex = 42, maValue = uno::Any 0 }, { mnIndex = 166, maValue = uno::Any 0 }, { mnIndex = 128, maValue = uno::Any 2 }, { mnIndex = 129, maValue = uno::Any 0 }, { mnIndex = 45, maValue = uno::Any 0 }, { mnIndex = 214, maValue = uno::Any 0 }, { mnIndex = 69, maValue = uno::Any com::sun::star::drawing::TextAnimationKind_NONE }, { mnIndex = 70, maValue = uno::Any com::sun::star::drawing::TextAnimationDirection_LEFT }, { mnIndex = 72, maValue = uno::Any 0 '\000' }, { mnIndex = 74, maValue = uno::Any 0 }, { mnIndex = 75, maValue = uno::Any 0 }, { mnIndex = 73, maValue = uno::Any 0 }, { mnIndex = 71, maValue = uno::Any 0 '\000' }, { mnIndex = 6, maValue = uno::Any 200 }, { mnIndex = 20, maValue = uno::Any 0 '\000' }, { mnIndex = 12, maValue = uno::Any com::sun::star::drawing::LineJoint_ROUND }, { mnIndex = 5, maValue = uno::Any "" }, { mnIndex = 24, maValue = uno::Any 0 }, { mnIndex = 25, maValue = uno::Any 1 '\001' }, { mnIndex = 1, maValue = uno::Any com::sun::star::drawing::LineStyle_SOLID }, { mnIndex = 139, maValue = uno::Any { X = 0, Y = 0, Width = 14001, Height = 9001 } }, { mnIndex = 144, maValue = uno::Any { X = 0, Y = 0, Width = 14001, Height = 9001 } }, { mnIndex = 248, maValue = uno::Any 9001 }, { mnIndex = 38, maValue = uno::Any com::sun::star::drawing::TextFitToSizeType_NONE }, { mnIndex = 15, maValue = uno::Any 10079487 }, { mnIndex = 52, maValue = uno::Any 0 '\000' }, { mnIndex = 245, maValue = uno::Any 0 }, { mnIndex = 10, maValue = uno::Any 0 '\000' }, { mnIndex = 22, maValue = uno::Any 0 }, { mnIndex = 23, maValue = uno::Any "" }, { mnIndex = 8, maValue = uno::Any "" }, { mnIndex = 35, maValue = uno::Any com::sun::star::drawing::TextVerticalAdjust_TOP }, { mnIndex = 247, maValue = uno::Any 14001 }, { mnIndex = 147, maValue = uno::Any 1 }, { mnIndex = 249, maValue = uno::Any 1 }, { mnIndex = 246, maValue = uno::Any 0 }, { mnIndex = 55, maValue = uno::Any 0 }, { mnIndex = 7, maValue = uno::Any 0 '\000' }, { mnIndex = 16, maValue = uno::Any 10079487 }, { mnIndex = 14, maValue = uno::Any com::sun::star::drawing::FillStyle_SOLID }, { mnIndex = 33, maValue = uno::Any 0 }, { mnIndex = 34, maValue = uno::Any com::sun::star::drawing::TextHorizontalAdjust_BLOCK }, { mnIndex = 31, maValue = uno::Any com::sun::star::drawing::RectanglePoint_MIDDLE_MIDDLE }, { mnIndex = 54, maValue = uno::Any 0 }, { mnIndex = 53, maValue = uno::Any 0 }, { mnIndex = 26, maValue = uno::Any 0 }, { mnIndex = 27, maValue = uno::Any 1 '\001' }, { mnIndex = 9, maValue = uno::Any 200 }, { mnIndex = 36, maValue = uno::Any 1 '\001' }, { mnIndex = 29, maValue = uno::Any 0 }, { mnIndex = 56, maValue = uno::Any 0 }, { mnIndex = 30, maValue = uno::Any 0 }, { mnIndex = 37, maValue = uno::Any 0 '\000' }, { mnIndex = 39, maValue = uno::Any 0 '\000' }, { mnIndex = 18, maValue = uno::Any 0 }, { mnIndex = 4, maValue = uno::Any 0 }, { mnIndex = 13, maValue = uno::Any com::sun::star::drawing::LineCap_BUTT }, { mnIndex = 11, maValue = uno::Any 0 }, { mnIndex = 3, maValue = uno::Any 0 }, { mnIndex = 190, maValue = uno::Any 1 }, { mnIndex = 187, maValue = uno::Any 0 }, { mnIndex = 131, maValue = uno::Any 4096 }, { mnIndex = 239, maValue = uno::Any 0 '\000' }, { mnIndex = 28, maValue = uno::Any com::sun::star::drawing::BitmapMode_REPEAT }, { mnIndex = 132, maValue = uno::Any 0 }, { mnIndex = 179, maValue = uno::Any 0 '\000' }, { mnIndex = 196, maValue = uno::Any 0 }, { mnIndex = 193, maValue = uno::Any 0 }, { mnIndex = 194, maValue = uno::Any 0 '\000' }, { mnIndex = 169, maValue = uno::Any 2 }, { mnIndex = 164, maValue = uno::Any 2 }, { mnIndex = -1, maValue = uno::Any { <com::sun::star::container::XIndexAccess> = { <com::sun::star::container::XElementAccess> = { <com::sun::star::uno::XInterface> = { _vptr.XInterface = 0x0 }, <No data fields>}, <No data fields>}, <No data fields>} }, { mnIndex = -1, maValue = empty uno::Any }}
The reproduction case document contains: <text:p> <draw:frame text:anchor-type="paragraph" draw:style-name="gr1" draw:name="Object 10" draw:text-style-name="P1" svg:height="9cm" svg:width="14cm" svg:y="1cm" svg:x="1cm"> <text:p draw:class-id="80243D39-6741-46C5-926e-069164ff87bb"></text:p> <draw:object-ole xlink:href="./Object" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame> </text:p> as opposed to <text:p> <draw:frame text:anchor-type="paragraph" draw:style-name="gr1" draw:name="Object 10" draw:text-style-name="P1" svg:height="9cm" svg:width="14cm" svg:y="1cm" svg:x="1cm"> <draw:object-ole draw:class-id="80243D39-6741-46C5-926e-069164ff87bb" xlink:href="./Object" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame> </text:p> At first sight, I thought this was invalid, since "that's not how it was done before". But then, I stumbled on bug 58571, which seems to say that this kind of construct is valid for most shapes, but not for charts. But I don't find where in the ODF specification a <draw:frame> is allowed to have a <text:p> child, except if that <text:p> child "refers to a chart". So I'm confused. On the contrary, http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415848_253892949 says: The <draw:frame> element has the following child elements: <draw:applet> 10.4.7, <draw:contour-path> 10.4.11.3, <draw:contour-polygon> 10.4.11.2, <draw:floating-frame> 10.4.10, <draw:glue-point> 10.3.16, <draw:image> 10.4.4, <draw:image-map> 10.4.13.2, <draw:object> 10.4.6.2, <draw:object-ole> 10.4.6.3, <draw:plugin> 10.4.8, <draw:text-box> 10.4.3, <office:event-listeners> 10.3.19, <svg:desc> 10.3.18, <svg:title> 10.3.17 and <table:table> 9.1.2.
(In reply to comment #1) > > At first sight, I thought this was invalid, since "that's not how it was > done before". But then, I stumbled on bug 58571, which seems to say that > this kind of construct is valid for most shapes, but not for charts. But I > don't find where in the ODF specification a <draw:frame> is allowed to have > a <text:p> child, except if that <text:p> child "refers to a chart". So I'm > confused. I did not want to apply with my bug fix that it is valid for any other case. I'm just not familiar enough with the shape export to disable it for anything else than the chart case where I know that it is invalid. The chart objects where it is allowed are not represented by the two values for which I disabled the export. > > On the contrary, > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1. > html#__RefHeading__1415848_253892949 says: > > The <draw:frame> element has the following child elements: <draw:applet> > 10.4.7, <draw:contour-path> 10.4.11.3, <draw:contour-polygon> 10.4.11.2, > <draw:floating-frame> 10.4.10, <draw:glue-point> 10.3.16, <draw:image> > 10.4.4, <draw:image-map> 10.4.13.2, <draw:object> 10.4.6.2, > <draw:object-ole> 10.4.6.3, <draw:plugin> 10.4.8, <draw:text-box> 10.4.3, > <office:event-listeners> 10.3.19, <svg:desc> 10.3.18, <svg:title> 10.3.17 > and <table:table> 9.1.2. So you have the same case that I had and you should put a breakpoint into that method and check that you can safely disable the text:p export for it.
So, I pushed to master (and submitted to gerrit for libreoffice-4-0) the minimal "check for NULLness before dereferencing pointer" patch. I'll let the domain experts decide if that's all that was needed, or if pLeft was supposed to be initialised somewhere (and then do that).
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=49a52d7631b2f29678ac0b20384525da5ad23938 fdo#64150 don't segfault when there is no line 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=924fdc8773a75de54b6ca6ceeaa686035b1f270d&h=libreoffice-4-0 fdo#64150 don't segfault when there is no line 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1e2fed7ab5886b2899b14eed4cb8c3b238524289&h=libreoffice-3-6 fdo#64150 don't segfault when there is no line It will be available in LibreOffice 3.6.7. 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.
No crash for me under Xubuntu 12.04 x86-64 with Version 4.0.4.0+ (Build ID: 828221dd980d4243788a1cab251e1c901a696d4) which has the patch. Crash reproduced with LO 4.0.3.3. Is there any reason to keep this bug report as unconfirmed ? Not sure if the patch completely fixes the bug, but if not fixed, it is at least new or assigned. Best regards. JBF
(In reply to comment #7) > Crash reproduced with LO 4.0.3.3. > Is there any reason to keep this bug report as unconfirmed ? Since you reproduced it, setting to NEW. Waiting for the experst to give an opinion as per comment 3.
On pc Debian x86-64 with master sources updated today, I gave a try. I had no crash but noticed these logs: warn:legacy.osl:30809:1:sw/source/core/unocore/unochart.cxx:1062: XLabeledDataSequence in data source contains 0 entries warn:legacy.osl:30809:1:sw/source/core/unocore/unochart.cxx:1062: XLabeledDataSequence in data source contains 0 entries warn:legacy.tools:30809:1:xmloff/source/draw/XMLShapeStyleContext.cxx:176: list-style not found for shape style Don't know if it can help.
so commit e3e7623bf6cecf0e32912347a58e5a2c7297099d added these 2 properties. hmm... ideally we'd be able to create a new border if one doesn't exist, but to do that requires knowing both the style and the width... ah well i'll just call it fixed for now