Bug Hunting Session
Bug 66097 - FILEOPEN Read error with images (large..) in DOCX file
Summary: FILEOPEN Read error with images (large..) in DOCX file
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: high normal
Assignee: Cao Cuong Ngo
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-23 20:07 UTC by J.D.
Modified: 2016-05-09 20:07 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
bt concerning "Missing base input stream" (3.57 KB, text/plain)
2013-06-26 20:58 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description J.D. 2013-06-23 20:07:46 UTC
In creation of an article for my club's newsletter, I'm having constant "Read-Error" problems while trying to load the JPGs I have embedded into the article. Because the newsletter editor uses MS Office, I have to offer the file in the DOCX format. Rather than creating the article in the native LO writer format and then saving it as a DOCX when its done, I thought I'd be able to save the file as the DOCX from the start... too often I've sent the editor the ODF version instead of the DOCX version.

The first part of the article I had only one image which caused this problem. In the second part, only the very first image loads, while ALL the rest show up as Read-Error boxes.

I've uploaded the article's file to my google drive account, the file is 13megs:
https://docs.google.com/file/d/0B0q8pfT0-of-S1VpY1BCdzNGLTQ/edit?usp=sharing
Comment 1 Cor Nouws 2013-06-23 20:20:16 UTC
Hi JD
Thanks for reporting.
I try to make the summary a bit more to the point. Hope that is fine for you as I do it now.
Also I set the importance lower - after all there is a work around (though you often forget to use it.)

Sorry that (for now) I do not try to reproduce the problem (maybe someone else does this). But I can well imagine that it happens.
Comment 2 J.D. 2013-06-23 20:31:39 UTC
Okay, since you didn't bother to tell me what this work around is, I re-upped the level of the bug.

Saying there is a work around and then not telling what it is doesn't do any good.
Comment 3 Cor Nouws 2013-06-23 22:18:51 UTC
(In reply to comment #0)
> ... too often I've sent the
> editor the ODF version instead of the DOCX version.

Not forgetting how to send the file, is the work around. 
Sorry, I thought that would have been clear ;)
Comment 4 J.D. 2013-06-23 22:22:25 UTC
That's like the work around Ford had for the Pinto... don't crash it!

Its not a work around, its a kluge. The point is LO should not claim to work with the DOCX format if it can't handle the calls needed for the format.

On your same train of thought, I should just get him to use LibreOffice instead of MS Office.

I'm NOT amused.
Comment 5 retired 2013-06-24 08:50:42 UTC
I've played with the document linked in the Description.

Loading in LO 4.1.0.1: First image displays fine, others show a reading error.
BUT, opening the same document with Word does show the same behavior. Also Word gives a warning that the document cannot be opened because there are issues with the content of the file.

So concerning opening the file: it seems LO behaves correct. From what I understand those images are fine in the original odf file.

J.D.: Could you please attach the original odf file so we can further test this. It seems the problem is introduced during the export to docx.

After providing that file please set this bug back to "UNCONFIRMED".

Thanks, james
Comment 6 J.D. 2013-06-24 12:19:41 UTC
James, I can't share the original LO format file because there is none. I created & edited the file as a docx. I am now recreating the documents from scratch in the native Open format, with hopes that doing that will allow me to then convert to docx at the end.

Not trying to be a jerk, but if there is a file format error, then LO put it there. I ran a disk check twice to be sure that it wasn't a bad sector, and until I can get a copy of SpinRite, thats all I can do.

By the way, thanks for checking it in MSO. Running only LO can have its problems.
Comment 7 Julien Nabet 2013-06-26 20:40:45 UTC
On pc Debian x86-64 with master sources updated today, I reproduced the problem.
I can see first image on the first page (a big old train) and the images of the last page (kids + old train again).
I noticed these console logs:
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL
warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop
warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop
warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop
warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop
warn:legacy.osl:25072:1:oox/source/helper/storagebase.cxx:71: StorageBase::StorageBase - missing base input stream
warn:sfx2.control:25072:1:sfx2/source/control/dispatch.cxx:1465: Childwindow slot missing: 10365
warn:sfx2.control:25072:1:sfx2/source/control/dispatch.cxx:1465: Childwindow slot missing: 10365
warn:sfx2.control:25072:1:sfx2/source/control/dispatch.cxx:1465: Childwindow slot missing: 10365
warn:legacy.osl:25072:1:sw/inc/swrect.hxx:299: SVRect() without Width or Height
Comment 8 Julien Nabet 2013-06-26 20:58:44 UTC
Created attachment 81510 [details]
bt concerning "Missing base input stream"

I don't know if it can help for the debug
Comment 9 Julien Nabet 2013-06-26 21:00:53 UTC
Michael: any idea how to dig on this tracker or who may help? I attached some logs and a bt but am quite stuck.
Comment 10 steve -_- 2015-04-15 12:48:40 UTC
OSX 10.10.3 and LO Version: 4.5.0.0.alpha0+
Build ID: 4e0d2fcdda3f639a05118b25ef99d8a4848302ce
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-04-13_06:20:15
Locale: de_

opens the file as expected.

Word 15.8 on OSX complains about a damaged file suggesting that were dealing with a broken document to begin with.

J.D. who ever put the error into the docx file, have you manage to re-create this document in a odt file? If so, could you attach that file? Also are you still seeing issues after storing as docx using that newly created file?

NEEDINFO, after providing the requesting info please reset the bug to NEW.
Comment 11 QA Administrators 2015-10-14 19:50:22 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

This NEEDINFO message was generated on: 2015-10-14
Comment 12 QA Administrators 2016-05-09 20:07:12 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

This INVALID Message was generated on: 2016-05-09