Bug 64150 - FILEOPEN crash opening document with text:p child of draw:frame
Summary: FILEOPEN crash opening document with text:p child of draw:frame
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:4.1.0 target:4.0.4 target:3.6.7
Keywords: regression
Depends on:
Blocks: 58371 64279
  Show dependency treegraph
 
Reported: 2013-05-02 13:52 UTC by Lionel Elie Mamane
Modified: 2013-07-02 14:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
reproduction case (5.48 KB, application/vnd.oasis.opendocument.text)
2013-05-02 13:52 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2013-05-02 13:52:02 UTC
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
  }}
Comment 1 Lionel Elie Mamane 2013-05-03 05:31:42 UTC
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.
Comment 2 Markus Mohrhard 2013-05-03 12:01:09 UTC
(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.
Comment 3 Lionel Elie Mamane 2013-05-03 19:31:46 UTC
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).
Comment 4 Commit Notification 2013-05-03 19:34:07 UTC
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.
Comment 5 Commit Notification 2013-05-03 23:40:47 UTC
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.
Comment 6 Commit Notification 2013-05-05 17:54:52 UTC
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.
Comment 7 Jean-Baptiste Faure 2013-05-11 14:58:45 UTC
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
Comment 8 Lionel Elie Mamane 2013-05-11 22:07:45 UTC
(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.
Comment 9 Julien Nabet 2013-05-27 21:02:39 UTC
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.
Comment 10 Michael Stahl (CIB) 2013-07-02 14:24:43 UTC
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