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
*** This bug has been marked as a duplicate of bug 99227 ***
Reproduced with 5.0 beta1. Xisco, please explain how is this fileopen bug a duplicate of filesave bug 99227?
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 ***
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.
Caolan fixed this in 70157, but it regressed again somewhere from 4.5 to 5.0.
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.
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?
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 ).
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.
Patch submitted for review: https://gerrit.libreoffice.org/32978
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.