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
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
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
Ouch, it looks like a get the document recovery dialog after restarting 5.3.0.0.alpha1, so move it to NEW.
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 ...
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.
(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
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.
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
@Terrence: ODFValidator can be run locally as well. Might be the attached document is too large for the server instance.
(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.
Trying to take a stab at this..
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?
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.
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
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.
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.
Pending review https://gerrit.libreoffice.org/31229 for 5-2
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.
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
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.
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.
(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
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.
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.
@gisel please open a new clean bug report about the residual issues and put this one under "See also"
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.