Bug Hunting Session
Bug 103493 - FILESAVE Write Error when a sheet with images, drawing objects and note/comment captions has been copied twice before itself, or even application crash
Summary: FILESAVE Write Error when a sheet with images, drawing objects and note/comme...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:5.4.0 target:5.3.0.1 target:5.2.4
Keywords: bibisectRequest, regression
Depends on:
Blocks: Calc-Images
  Show dependency treegraph
 
Reported: 2016-10-25 12:36 UTC by gisel.avaleazar
Modified: 2017-02-28 17:10 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
sample (2.49 MB, application/vnd.oasis.opendocument.spreadsheet)
2016-10-25 14:47 UTC, Xisco Faulí
Details
officeotron diagnoses 400000 errors in the attachment (6.15 KB, text/plain)
2016-11-01 20:21 UTC, Terrence Enger
Details
stripped down version of the test case document (123.54 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-11-24 17:27 UTC, Eike Rathke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gisel.avaleazar 2016-10-25 12:36:33 UTC
Description:
In my spreadsheet (downloadable here: https://www.dropbox.com/s/ioplw9cl7jubv5d/LotroPlan%203.8.ods?dl=0) the user needs to copy the sheet named "Character Name". Lately this is not possible anymore. See this history:

In version win x86 4.4.7.2: the user can copy as many times as he likes and is able to save the document.

In version 5.0: the user can copy this sheet 1 time and save the document without a problem. After a second copy the save process gives a Write Error message. After restarting Calc the user can copy the sheet again 1 time and save. etc.

In version 5.1 and above: when the sheet is copied and you save the document then the application crashes. This is also in 5.3.0.0alpha1

Steps to Reproduce:
1. Copy sheet "Character Name" to "Character Name_2"
2. (Optional) Copy sheet "Character Name" to "Character Name_3"
3. Save

Actual Results:  
application crash

Expected Results:
saved document


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Comment 1 Xisco Faulí 2016-10-25 14:34:10 UTC
I get the following error

Error saving the document LotroPlan 3.8:
Write Error.
The file could not be written.

in 

Version: 5.3.0.0.alpha1
Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 2 Xisco Faulí 2016-10-25 14:47:41 UTC
Created attachment 128252 [details]
sample

it looks like the error I'm getting can't be reproducible in

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

So i'm creating another bug for the error problem in linux.

Someone must confirm this one in windows though
Comment 3 Xisco Faulí 2016-10-25 14:55:22 UTC
Ouch, it looks like a get the document recovery dialog after restarting 5.3.0.0.alpha1, so move it to NEW.
Comment 4 Terrence Enger 2016-11-01 20:21:49 UTC
Created attachment 128411 [details]
officeotron diagnoses 400000 errors in the attachment

Of course, input errors do not excuse the crash, but the may be a
cause.  This is from officeotron 0.7.4 running on debian-stretch ...
Comment 5 Terrence Enger 2016-11-10 16:49:48 UTC
On Vista in win5.3 bibisect repository with source hash 6fe0706
(committed 2016-11-05), I copied that worksheet twice and then saved
the file.  It took several minutes (I did not hang around), but
eventually Calc became responsive again, and I was able to close the
program normally.
Comment 6 Eike Rathke 2016-11-17 14:16:42 UTC
(In reply to Terrence Enger from comment #4)
> Created attachment 128411 [details]
> officeotron diagnoses 400000 errors in the attachment

AFAIK officeotron doesn't validate ODF 1.2 extended, hence all extension namespaces are considered errors.

The validator of choice is ODFValidator, see https://wiki.documentfoundation.org/ODF#ODFValidator
Comment 7 Terrence Enger 2016-11-17 15:23:07 UTC
Thank you, Eike, for the pointer to ODFValidator.  Unfortunately, the
first server reports "internal server error" and the second presents a
java exception report headed "HTTP Status 500 -
org.apache.jasper.JasperException: javax.servlet.ServletException:
java.lang.OutOfMemoryError: Java heap space".  So far as I can
remember, I have never had good results from ODFValidator.
Comment 8 Eike Rathke 2016-11-17 20:02:31 UTC
Note: the only real error visible in the attached officeotron validation excerpt, an empty style:text-position="" attribute, is fixed with https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=8aec9057a169acfda6f2d986af93edca54677fd2
Comment 9 Eike Rathke 2016-11-17 20:31:27 UTC
@Terrence: ODFValidator can be run locally as well. Might be the attached document is too large for the server instance.
Comment 10 Eike Rathke 2016-11-19 22:54:13 UTC
(In reply to Xisco Faulí from comment #3)
> Ouch, it looks like a get the document recovery dialog after restarting
> 5.3.0.0.alpha1, so move it to NEW.
Were you by chance using a dbgutil build to test? Asking because I ran into an assertion with a dbgutil build that forces the application to crash:

sax/source/expatwrap/saxwriter.cxx:1143: virtual void {anonymous}::SAXWriter::endElement(const rtl::OUString&): Assertion `aName == m_pSaxWriterHelper->m_DebugStartedElements.top()' failed.

Which would explain your document recovery. I don't get a crash in a non-dbgutil build, but I do get the error message from comment 1 as well.
Comment 11 Eike Rathke 2016-11-22 10:50:27 UTC
Trying to take a stab at this..
Comment 12 gisel.avaleazar 2016-11-24 11:56:28 UTC
I lately don't experience an immediate crash after a second copy with a modified version of the spreadsheet.
However, I still do have them when I make a larger number of sheet copies.
It's like the size of the document does matter in this. After a certain point I can only copy/save with a reload in between.
Saving corrupts something which makes the next save crash the application?
Comment 13 Eike Rathke 2016-11-24 12:39:04 UTC
It's some combination of drawing layer objects on that 'Character Name' sheet, i.e. comment boxes, hidden drawing objects and hidden images, that if copied twice on save makes obtaining some properties for the images fail, which leads to an exception and thus saving fails. I'm currently trying to strip that huge document down to something more narrow which still exposes the failure.
Comment 14 Eike Rathke 2016-11-24 17:27:34 UTC
Created attachment 128993 [details]
stripped down version of the test case document

This document has only one table with comments and hidden drawing objects and images. When copied twice and saving the Write Error still appears.
Formatting and formula cells have been deleted, but oddly deleting the few remaining text cells makes the bug disappear.

The (first) exception thrown is under xPropSet->getPropertyValue("GraphicStreamURL") in xmloff/source/draw/shapeexport.cxx XMLShapeExport::ImpExportGraphicObjectShape()
(and for properties "GraphicURL" and "ReplacementGraphicURL" as well if one places each in try/catch blocks for testing purposes).

Interestingly these warnings are also triggered
xmloff/source/draw/shapeexport.cxx:648: exportShape callings do not correspond to collectShapeAutoStyles calls!: com.sun.star.drawing.CaptionShape

that seem to be related and a bunch of
xmloff/source/draw/shapeexport.cxx:626: XMLShapeExport::exportShape(): no shape info collected for a given shape
Comment 15 Commit Notification 2016-11-26 10:40:45 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a2a7436b4041bb34b01a183b9264af8488d1af3

Resolves: tdf#103493 copying note captions needs a completed destination sheet

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.
Comment 16 Commit Notification 2016-11-26 10:56:44 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6af70ec9d0f87553a7fb795d957d41cf6d2d7c6d&h=libreoffice-5-3

Resolves: tdf#103493 copying note captions needs a completed destination sheet

It will be available in 5.3.0.1.

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 17 Eike Rathke 2016-11-26 11:00:56 UTC
Pending review https://gerrit.libreoffice.org/31229 for 5-2
Comment 18 Commit Notification 2016-11-29 14:55:00 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bea103fa2c331d776c39e126d0d086983d7ec28b&h=libreoffice-5-2

Resolves: tdf#103493 copying note captions needs a completed destination sheet

It will be available in 5.2.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 19 gisel.avaleazar 2016-11-30 08:52:13 UTC
Thank you!

Is it already available in any build? I've tested the original document with [ http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2016-11-29_23.29.46/libo-master~2016-11-29_23.29.46_LibreOfficeDev_5.4.0.0.alpha0_Win_x86.msi ], but I'm still getting the same problem on the 5th sheet copy:

1. copy sheet "character name" before "jewelry": "character name_2"
2. save
3. copy sheet "character name" before "jewelry": "character name_3"
4. save
5. copy sheet "character name" before "jewelry": "character name_4"
6. save
7. copy sheet "character name" before "jewelry": "character name_5"
8. save
9. copy sheet "character name" before "jewelry": "character name_6"
10. save
crash
Comment 20 Eike Rathke 2016-12-01 09:26:48 UTC
Builds from 2016-11-29 should have it included.
Btw, for dev-builds it helps if you include the Help->About information like Build-ID.

However, I don't encounter a problem with your scenario. Might it be that with the 32-bit version your system simply runs out of memory during save? If so, you could try a Win-x86_64 build once available, currently there isn't.
Comment 21 gisel.avaleazar 2016-12-01 11:06:51 UTC
I don't know.. I have a 16gb system, but with win32 I guess applications have 4gb. It could be.

By the way, I don't know if this is related, I was just testing with the latest builds and I noticed that saving my original document is very much broken now.
When I don't make any changes and just save and reload the document then weird things have happened to the "character name" sheet. See http://i.imgur.com/zfeVXVU.png Also a large number of lines have been inserted further down: empty lines but with comments from top section.

I don't have this corruption with "fresh" win32 Version: 5.2.3.3
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf

Testing win32 and x64 version 5.2.3.3 results:
win32: fatal error after 5th copy
x64: fatal error after 5th copy

So no difference concerning memory there I guess.
Comment 22 Eike Rathke 2016-12-01 13:02:17 UTC
(In reply to gisel.avaleazar from comment #21)
> By the way, I don't know if this is related, I was just testing with the
> latest builds and I noticed that saving my original document is very much
> broken now.
> When I don't make any changes and just save and reload the document then
> weird things have happened to the "character name" sheet. See
> http://i.imgur.com/zfeVXVU.png Also a large number of lines have been
> inserted further down: empty lines but with comments from top section.
Unrelated, and probably fixed with https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=c038d88c228bb2f4d0dde88f59ee4b9c6620687e
Comment 23 gisel.avaleazar 2016-12-11 09:55:03 UTC
Hello again.
I've done the same test again with version: 5.3.0.0.beta1+ (x64)
Build ID: 7f47d68c4310b8bae09286a81036a6fa669a170 (dec 8th) and getting the same result again (fatal error after 5th copy).
I've also done the same test on a win32 AMD system using the win32 version with the same result.
Comment 24 gisel.avaleazar 2016-12-23 12:05:37 UTC
Results for "Version: 5.2.4.2 (x64)
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0":
1) Weird effects (http://i.imgur.com/zfeVXVU.png) have disappeared.
2) Still Fatal Error at saving after 5th character sheet copy.
Comment 25 tommy27 2017-01-03 15:38:32 UTC
@gisel
please open a new clean bug report about the residual issues and put this one under "See also"
Comment 26 Xisco Faulí 2017-02-28 17:10:25 UTC
As mentioned in comment 25, if residual issues are found, please open a follow-up bug and put this one under "See also"
Closing as RESOLVED FIXED.