Bug 104414 - FILEOPEN DOCX: SAXParseException: unknown error' due to Bezier of non-supported ellipse segments for VML shape
Summary: FILEOPEN DOCX: SAXParseException: unknown error' due to Bezier of non-support...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: high major
Assignee: Mike Kaganski
URL:
Whiteboard: interoperability target:5.4.0
Keywords: filter:docx
Depends on:
Blocks:
 
Reported: 2016-12-05 10:11 UTC by Telesto
Modified: 2019-05-15 09:32 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2016-12-05 10:11:21 UTC
Description:
File format error found at position cannot be changed with this method
SAXParseException: '[word/document.xml line 2]: unknown error', Stream 'word/document.xml', Line 2, Column 29326(row,col).

Steps to Reproduce:
1. Open attachment 87146 [details] (bug 70157)

Actual Results:  
SAXParseException

Expected Results:
No SAXParseException


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in:
Version: 5.4.0.0.alpha0+
Build ID: 33f5bc54aaa7fe7aa9335726e30f9c349155e04d
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-12-01_23:21:05
Locale: nl-NL (nl_NL); Calc: CL

and in:
Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: en-US (nl_NL)

but not with:
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL



User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Xisco Faulí 2016-12-05 15:14:57 UTC Comment hidden (obsolete)
Comment 2 Timur 2016-12-06 12:41:29 UTC Comment hidden (obsolete)
Comment 3 Xisco Faulí 2016-12-06 12:50:09 UTC
Basically because I bisected this issue and it was introduced by the same commit as bug 99227 so I can assume the problem here is at save time, when the document attached was saved, not when it's opened

*** This bug has been marked as a duplicate of bug 99227 ***
Comment 4 Timur 2016-12-06 13:12:51 UTC
Sorry, trying to make this clear for all. 
I guessed you had already bisected this but you should write the commit. 
If it's "DOCX import: better error handling than "catch (...) {}"" then it's not that, because it's just error handling. 
If it's "tdf#95188: enable import of shapes in footnotes in .docx" than version doesn't correspond.
Attachment 87146 [details] is valid when tested with XML Productivity Tool, so we can't assume it's saved in LO and I didn't understand from Bug 70157 it was.
Comment 5 Timur 2016-12-19 13:15:01 UTC Comment hidden (obsolete)
Comment 6 Aron Budea 2017-01-05 21:08:20 UTC
Yeah, this is the commit where the document stops opening:
 07335c0a11142b308d6d73dd6a7176e52e5a483f is the first bad commit
commit 07335c0a11142b308d6d73dd6a7176e52e5a483f
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Wed May 20 02:03:48 2015 -0500

    source ebf767eeb2a169ba533e1b2ffccf16f41d95df35

    source ebf767eeb2a169ba533e1b2ffccf16f41d95df35
	
	author	Michael Stahl <mstahl@redhat.com>	2015-01-22 11:50:07 (GMT)
committer	Michael Stahl <mstahl@redhat.com>	2015-01-22 12:58:10 (GMT)
commit ebf767eeb2a169ba533e1b2ffccf16f41d95df35 (patch)
tree 81946ae1fdee22ebf6f2543d0a965304528205f7
parent 825e4995220209362c13ed5f07c98e43a5f456de (diff)
writerfilter: DOCX import: better error handling than "catch (...) {}"

Let's assume there are problems during document import, which never worked correctly anyway, and thus this probably isn't really a regression. 
Nevertheless, I'm adding bug 99227 as related, maybe there's a connection between the two.
Comment 7 Timur 2017-01-06 13:02:32 UTC
Aron, thank you. 
But, "Michael's patch made possible to see quite a number of different problems that all were simply ignored in previous versions. So, the diagnostic is not the cause of all those; it just revealed them."
So, you what you did is similar to Xisco. Bug 99227 shouldn't be related. 

Document worked as you can see in Bug 70157 for LO 4.4. It also says it was fixed for 4.5, so I concluded "it regressed again somewhere from 4.5 to 5.0". 
Can you please mark that commit as good in order to find the bad one?
Comment 8 Mike Kaganski 2017-01-07 07:46:15 UTC
The problem is when the following line is executed:

> ooxlo.dll!oox::shape::ShapeContextHandler::getShape() Line 430
> writerfilterlo.dll!writerfilter::ooxml::OOXMLFastContextHandlerShape::sendShape(long Element) Line 1623
> writerfilterlo.dll!writerfilter::ooxml::OOXMLFastContextHandlerWrapper::lcl_createFastChildContext(long Element, const com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> & Attribs) Line 1888
> writerfilterlo.dll!writerfilter::ooxml::OOXMLFastContextHandler::createFastChildContext(long Element, const com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> & Attribs) Line 229
> expwraplo.dll!`anonymous namespace'::Entity::startElement(`anonymous-namespace'::Event * pEvent) Line 463
> expwraplo.dll!sax_fastparser::FastSaxParserImpl::callbackStartElement(const unsigned char * localName, const unsigned char * prefix, const unsigned char * URI, int numNamespaces, const unsigned char * * namespaces, int numAttributes, int __formal, const unsigned char * * attributes) Line 1200
> expwraplo.dll!call_callbackStartElement(void * userData, const unsigned char * localName, const unsigned char * prefix, const unsigned char * URI, int numNamespaces, const unsigned char * * namespaces, int numAttributes, int defaultedAttributes, const unsigned char * * attributes) Line 301
> libxml2.dll!xmlParseStartTag2(_xmlParserCtxt * ctxt, const unsigned char * * pref, const unsigned char * * URI, int * tlen) Line 9794
> libxml2.dll!xmlParseTryOrFinish(_xmlParserCtxt * ctxt, int terminate) Line 11591
> libxml2.dll!xmlParseChunk(_xmlParserCtxt * ctxt, const char * chunk, int size, int terminate) Line 12496
> expwraplo.dll!sax_fastparser::FastSaxParserImpl::parse() Line 1039
> expwraplo.dll!sax_fastparser::FastSaxParserImpl::parseStream(const com::sun::star::xml::sax::InputSource & maStructSource) Line 821
> expwraplo.dll!sax_fastparser::FastSaxParser::parseStream(const com::sun::star::xml::sax::InputSource & aInputSource) Line 1379
> writerfilterlo.dll!writerfilter::ooxml::OOXMLDocumentImpl::resolve(writerfilter::Stream & rStream) Line 504
> writerfilterlo.dll!WriterFilter::filter(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aDescriptor) Line 190
> sfxlo.dll!SfxObjectShell::ImportFrom(SfxMedium & rMedium, const com::sun::star::uno::Reference<com::sun::star::text::XTextRange> & xInsertPosition) Line 2263
> ...

(call stack from VS2013).
When this happens, the element being processed is the first <v:textbox>, and looks like LO has troubles executing pShape->convertAndInsert( xShapes ).
Comment 9 Mike Kaganski 2017-01-07 18:29:38 UTC
The problem is that the Bezier that is created for that VML shape (cloud) is composed only of non-supported (yet) ellipse segments, so it ends up empty. Trying to add a text box for that throws.
Comment 10 Mike Kaganski 2017-01-11 21:52:19 UTC
Patch submitted for review: https://gerrit.libreoffice.org/32978
Comment 11 Commit Notification 2017-01-12 15:49:28 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6bc2c54711fc3e798c440978a78d03488f14f0d9

tdf#104414: don't stop on exception from SwXFrame::setPosition

It will be available in 5.4.0.

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.