Description: Attached ODS file when open with LibreOffice 5.4.5.1 raise Incorrect format error. The same file opened with OpenOffice 4.1.3 do it well. Regads, Mariano Steps to Reproduce: 1. Open attached file called: REPORT_UNIT_TO_ODS.ods 2. 3. Actual Results: As see in attached file LibreOffice5.4.5.1.png Expected Results: As see in attached file OpenOffice4.1.3.png Reproducible: Always User Profile Reset: Yes Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Created attachment 140208 [details] Error opening REPORT_UNIT_TO_ODS.ods file
Created attachment 140209 [details] File REPORT_UNIT_TO_ODS.ods well opened with OpenOffice 4.1.3
Created attachment 140210 [details] ODS file that causes the error
Regression introduced by: author Mohammed Abdul Azeem <azeemmysore@gmail.com> 2016-09-05 14:38:30 +0530 committer Michael Meeks <michael.meeks@collabora.com> 2017-01-25 11:20:48 +0000 commit 8154953add163554c00935486a1cf5677cef2609 (patch) tree d8e148e84aa1e164a2358827085f4d9240ce5e31 parent 657eea01046c7f39ee8ca4545241372177385946 (diff) ScXMLTableRowCellContext implements fast interfaces: Implementation of fast interfaces for contexts in path from ScXMLImport::CreateFastContext to ScXMLTableRowCellContext. FastParser is enabled and duplicates are avoided at all possible places. OOoXML filters still need those legacy paths we removed, so I had to temporarily map them to fast elements, which would increase their load time, but hopefully it should help us in the long run. Bisected with: bibisect-linux-64-5.4 Adding Cc: to Mohammed Abdul Azeem
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is still present. About information: Versión: 6.2.4.2 (x64) Id. de compilación: 2412653d852ce75f65fbfa83fb7e7b669a126d64 Subprocs. CPU: 4; SO: Windows 10.0; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded
*** Bug 131059 has been marked as a duplicate of this bug. ***
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed this on console logs: warn:fwk.desktop:319071:319071:framework/source/services/desktop.cxx:1063: Desktop disposed before terminating it warn:fwk.desktop:319071:319071:framework/source/services/desktop.cxx:179: Desktop not terminated before being destructed warn:sc.filter:319101:319101:sc/source/filter/xml/xmlwrap.cxx:217: SAX parse exception caught while importing: com.sun.star.xml.sax.SAXParseException message: [file:///tmp/REPORT_UNIT_TO_ODS.ods line 2]: Extra content at the end of the document wrapped: void PublicId: SystemId: file:///tmp/REPORT_UNIT_TO_ODS.ods LineNumber: 2 ColumnNumber: 1 warn:xmloff.core:319101:319101:xmloff/source/core/xmlimp.cxx:739: SvXMLImport::startElement: missing context for element style:default-style warn:xmloff.core:319101:319101:xmloff/source/core/xmlimp.cxx:739: SvXMLImport::startElement: missing context for element style:paragraph-properties warn:xmloff.core:319101:319101:xmloff/source/core/xmlimp.cxx:739: SvXMLImport::startElement: missing context for element office:forms warn:xmloff.core:319101:319101:xmloff/source/core/xmlimp.cxx:739: SvXMLImport::startElement: missing context for element text:bookmark
Created attachment 158396 [details] bt with debug symbols Here's the bt from throw xml::sax::SAXParseException
I noticed that meta.xml contained just: <?xml version="1.0" encoding="UTF-8"?> and nothing else afterwards.
With this patch, I can open the file: diff --git a/sax/source/fastparser/fastparser.cxx b/sax/source/fastparser/fastparser.cxx index f70995763c4c..d2cfb1417afa 100644 --- a/sax/source/fastparser/fastparser.cxx +++ b/sax/source/fastparser/fastparser.cxx @@ -1044,13 +1044,6 @@ void FastSaxParserImpl::parse() nRead = rEntity.maConverter.readAndConvert( seqOut, BUFFER_SIZE ); if( nRead <= 0 ) { - if( rEntity.mpParser != nullptr ) - { - if( xmlParseChunk( rEntity.mpParser, reinterpret_cast<const char*>(seqOut.getConstArray()), 0, 1 ) != XML_ERR_OK ) - rEntity.throwException( mxDocumentLocator, true ); - if (rEntity.hasException()) - rEntity.throwException(mxDocumentLocator, true); - } break; } This part has been put with: https://cgit.freedesktop.org/libreoffice/core/commit/?id=82d08580e368afbc9d73da3613845a36a89b0a8c author Luboš Luňák <l.lunak@collabora.com> 2014-11-14 17:13:41 +0100 committer Luboš Luňák <l.lunak@collabora.com> 2014-11-14 17:20:00 +0100 commit 82d08580e368afbc9d73da3613845a36a89b0a8c (patch) tree ef353fcfd8d7b427a0ecf2281eb7c0264f6fc9a6 parent 37800290245fd0462295a8bbaabd9d761929fa65 (diff) switch saxparser from expat to libxml2 I don't know if it's ok or not. nRead is sal_Int32 but it seems it can't be negative. Also perhaps meta.xml with just encoding is ok but another xml file with just encoding is not ok => a bit stuck here.
Hi Noel, I'm adding you as CC to this ticket since the commit that introduced this is related to FastParser and you have done some work related to FastParsers recently...
If Julien is correct in comment#10, then that is technically not a well-formed XML document. Probably we used to accept it because we were being a little sloppy. I suggest you go up the stack to just above the parser, and check if the data-stream contains exactly that sequence of chars, and then just return OK.
(In reply to Noel Grandin from comment #13) > If Julien is correct in comment#10, then that is technically not a > well-formed XML document. Here's what I did: julien@debianamd:/tmp/jul$ mv REPORT_UNIT_TO_ODS.ods REPORT_UNIT_TO_ODS.zip julien@debianamd:/tmp/jul$ unzip REPORT_UNIT_TO_ODS.zip Archive: REPORT_UNIT_TO_ODS.zip inflating: content.xml inflating: meta.xml inflating: settings.xml inflating: styles.xml inflating: mimetype inflating: META-INF/manifest.xml julien@debianamd:/tmp/jul$ cat meta.xml <?xml version="1.0" encoding="UTF-8"?> julien@debianamd:/tmp/jul$ > Probably we used to accept it because we were being a little sloppy. > I suggest you go up the stack to just above the parser, and check if the > data-stream contains exactly that sequence of chars, and then just return OK. Here's the bt from the method quoted in my previous comment: #0 0x00007fffe4c69570 in sax_fastparser::FastSaxParserImpl::parse() (this=0x1b0a270) at sax/source/fastparser/fastparser.cxx:1044 #1 0x00007fffe4c68997 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) (this=<optimized out>, rStructSource=...) at sax/source/fastparser/fastparser.cxx:869 #2 0x00007ffff1e0dc21 in SvXMLImport::parseStream(com::sun::star::xml::sax::InputSource const&) (this=0x1b08620, aInputSource=...) at xmloff/source/core/xmlimp.cxx:488 #3 0x00007fffe42e88c0 in ScXMLImportWrapper::ImportFromComponent(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::frame::XModel> const&, com::sun::star::uno::Reference<com::sun::star::xml::sax::XParser> const&, com::sun::star::xml::sax::InputSource&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, bool) (this=0x7fffffff1d38, xContext=..., xModel=..., xParser=..., aParserInput=..., sComponentName=..., sDocName=..., sOldDocName=..., aArgs=..., bMustBeSuccessfull=false) at sc/source/filter/xml/xmlwrap.cxx:189 #4 0x00007fffe42ea712 in ScXMLImportWrapper::Import(ImportFlags, ErrCode&) (this=0x7fffffff1d38, nMode=<optimized out>, rError=...) at sc/source/filter/xml/xmlwrap.cxx:432 #5 0x00007fffe43fcecc in ScDocShell::LoadXML(SfxMedium*, com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&) (this=0x1a5ef70, pLoadMedium=0x1a65fa0, xStor=...) at sc/source/ui/docshell/docsh.cxx:481 #6 0x00007fffe43fde38 in ScDocShell::Load(SfxMedium&) (this=0x1a5ef70, rMedium=...) at sc/source/ui/docshell/docsh.cxx:628 #7 0x00007ffff6923107 in SfxObjectShell::LoadOwnFormat(SfxMedium&) (this=0x1a5ef70, rMedium=...) at sfx2/source/doc/objstor.cxx:3033 #8 0x00007ffff692437b in SfxObjectShell::DoLoad(SfxMedium*) (this=0x1a5ef70, pMed=0x1a65fa0) at sfx2/source/doc/objstor.cxx:674 #9 0x00007ffff6954d2d in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x1a62260, seqArguments=...) at sfx2/source/doc/sfxbasemodel.cxx:1879 #10 0x00007ffff69eddcd in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) (this=<optimized out>, rArgs=..., _rTargetFrame=...) at sfx2/source/view/frmload.cxx:680 #11 0x00007fffe54432f0 in framework::LoadEnv::impl_loadContent() (this=0x195a468) at framework/source/loadenv/loadenv.cxx:1157 Where could I bypass and how?
I gave a try with https://gerrit.libreoffice.org/c/core/+/90446
(In reply to Noel Grandin from comment #13) > If Julien is correct in comment#10, then that is technically not a > well-formed XML document. Just removing meta.xml from the document makes it open OK. And yes, having no elements in the XML after prolog (here consisting of declaration) makes the XML not well-formed [1]. [1] https://www.w3.org/TR/2008/REC-xml-20081126/#sec-well-formed
Personally I don't see why: 1. this has such a high importance. Isn't it more important to file bugs to whatever tries to generate invalid documents? 2. this should be fixed at all. Why accept broken data - unless it's really impossible to fix the root (prevent these documents from appearing)?
(In reply to Mike Kaganski from comment #16) > (In reply to Noel Grandin from comment #13) > > If Julien is correct in comment#10, then that is technically not a > > well-formed XML document. > > Just removing meta.xml from the document makes it open OK. > And yes, having no elements in the XML after prolog (here consisting of > declaration) makes the XML not well-formed [1]. > > [1] https://www.w3.org/TR/2008/REC-xml-20081126/#sec-well-formed Indeed. In this case, perhaps should we change the patch to replace the return part by a SAL_WARN ?
Created attachment 158677 [details] file fixed Here what I did: - applied locally my abandoned patch to be able to open the file - opened the file - saved it in another name - removed the abandoned patch from local sources - opened the new file
Maybe just a personal opinion, but I wouldn't do anything about this. The document is broken, generated by a broken implementation. Unfortunately we don't know the generator because that information is supposed to be stored in the <meta:generator> element, which the generator chose to not include.. To the original bug reporter: The file name REPORT_UNIT_TO_ODS.ods suggests some ODF/.ods generating report tool, what is it? I'd recommend to file a bug with that if it's still in use, otherwise forget about it. The document fixed by Julien (thanks!) is now attached, I think we can close this bug as notabug/wontfix/notourbug/whatever.
Hello Mariano, Could you please explain how the document was generated ?
Hi Xisco, the document is generated via Jasperserver 7.1.0 Community Version, exporting document. Regards, Mariano