I have an .odt file, but when I modify it and try to save it, I almost always get an error. It's usually "Error in writing sub-document content.xml", but I've also had errors referring to style.xml, "General I/O error", and even one involving ${arg1}. I sent the file as an email attachment to another Windows computer, and I could modify and save it there with no problems. I've tried copying it on the same computer, and even copied it to Google Docs and back, with no success. I downloaded the latest version (5.2.0.1) of LibreOffice, even clicking on "Repair": still getting the same error. Even copying a few pages of the document to another file and trying to save it usually failed. This is getting very frustrating!
That sounds very frustrating indeed. For starters, can you tell me which LibreOffice version did you use first, and which was used on the other computer? This error might be related to specific parts of the document, so it might be worth systematically copying different parts, and trying to save the document, thus narrowing down the parts that might cause this failure. Of course this only works if the issue is consistent, if the same piece of document can sometimes be saved, but not always, then unfortunately this method provides no useful information.
You can try to reset/rename your userprofile: https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile
Aron: Thanks. I think I tried 5.1.4 first; then as that never worked, tried the latest (5.2.0). I don't recall the version on the other computer, because that one stopped working and we recycled it. I have tried saving part of the document, and this fails when I save only a few pages. Also, the point at which it fails varies, apparently non-deterministically.
MM: Thanks, I looked in Tools -> Options -> LibreOffice -> Paths and found a number of files, not all in the same directory. However, most of them were in a directory ending ... LibreOffice\4\user but there was nothing in there called a "Profile". Anyway, I renamed that directory, and opened my file again, but this time it was "Read Only", despite not being marked that way under "Properties". I tried "Save As" to save a copy, but I got "Error in writing sub-document content.xml",something I've seen before. :(
When you say nondeterministically, does it mean the exact same steps sometimes cause error, the other times don't? Or it's just so far there were no clear-cut identifiable steps that caused the error? Very little can be done without a sample document and proper reproduction steps. How complex is the document, what could be the incriminating subdocument? Could you try copying the content into a new document, seeing if maybe that gets rid of this issue? You could also copy the document with .zip extension, unzip it, and look into the XML files for anomalies, but I don't really know what to look for (plus the file could be correct in its saved state). Adding needAdvice keyword, hoping a developer can give some directions.
Aron: I copied it, a few pages at a time, saving as I went. This was OK for a while. Then, just to check, I made a trivial change (added a space, then deleted it), and I got "Error in writing sub-document content.xml". So I deleted pages, getting back to where I had successfully saved before, and I got the error again. Eventually, I had deleted almost all of the pages, and I could save once again. Then I did the space+delete thing again, tried to save, and got the error again. The file is long: 392 pages, with illustrations, table of contents, and index. It was previously in an old version of Word, but I converted it to OpenOffice with no problems a few years ago.
When you mentioned you got back to an almost empty document, saved, and the you got the error after space+delete, did the issue come up after restarting LibreOffice, reopening the document, and repeating the same space+delete? Could you produce a document you could attach? I'm thinking, maybe insert some random text, repeat some of those steps you mentioned, delete everything but the random text, and try to see if the error comes up again after a save. If working on the document would be important for you in the meantime, you could try with earlier LibreOffice versions (since you mentioned another computer with an unknown version had no issues with the file). I'd suggest latest releases from previous main versions, like 5.0.6.2 or 4.4.7.2, downloadable from [1]. You can find details on how to install it in parallel with the current version at [2] (SI-GUI is a pretty neat tool). [1] http://downloadarchive.documentfoundation.org/libreoffice/old/ [2] https://wiki.documentfoundation.org/Installing_in_parallel/Windows
Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
Sorry, haven't had much time recently. Also the document is somewhat controversial, but I'll think about producing a version I'd be happy to publish.
Created attachment 126313 [details] Extract from my big file. Saving sometimes works, sometimes doesn't Sometimes, when I try to save, I get "Error in writing sub-document $(ARG1), sometimes it saves OK, without making any changes. I have seen other errors, but I'm only getting this one currently.
Thanks for the sample, Mark! I've been trying to reproduce the bug in LO 5.2.0.2 with it, without success so far, unfortunately. I did get bad allocation error a couple of times when trying to delete large portions of text, but that wasn't consistent, either. Very strange.
(In reply to Aron Budea from comment #11) > Thanks for the sample, Mark! > I've been trying to reproduce the bug in LO 5.2.0.2 with it, without success > so far, unfortunately. > I did get bad allocation error a couple of times when trying to delete large > portions of text, but that wasn't consistent, either. Very strange. Aron: I really appreciate your taking trouble to investigate this. Currently, when I try to save it (without making any changes), I get any one of four results, apparently at random: o success o "Error in sub-document styles.xml" o "Error in sub-document content.xml" o "Error in writing sub-document $(ARG1)" Thanks again.
I was able to save it over 20 times with no problems. Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: 62442d9066ea553a4b68b8a93fa54748cbe96e06 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-07-19_00:20:50 Locale: fi-FI (fi_FI); Calc: CL
*** Bug 101456 has been marked as a duplicate of this bug. ***
Raising severity to critical, as the issue causes data loss.
Well, after a month's break, I find I can now modify and save my big file with no problems. Let's hope it stays like this.
Seems I spoke too soon. Opening LibreOffice today, it said that it had to recover my file. Now it's not saving, giving "Error in writing sub-document content.xml" or, occasionally, "Error in writing sub-document style.xml".
If you can create a reproducible situation, that would help of course, for example: when LO says "recovering" - what is it recovering (I'm a bit of a newbie)? if there are temp files that constitute the "pre-recovery" files from which LO recovers, and you can copy those (save them outside of LO's reach for example) and therefore "repeatedly and consistently recreate" the "failure to recover this large file", that would of course be very useful.
Mark, someone else was having a similar issue recently (bug 101790). A complete uninstall&reinstall fixed their issue, it might be worth giving that a try (while you're at it, you might want to install 5.2.1.2 prerelease version, which will most likely be the final 5.2.1).
Aron: Thanks again. My wife created some .odf files, which came out fine. I also restarted my computer, in case that was the problem. But the next time I opened LibreOffice, my file was seriously corrupted: it seems none of the formatting is rendered, although the text seems to be intact. Next, I read your email and downloaded and installed 5.2.1.2 as you suggested. Now my file is still corrupted, but I have another, slightly older version of the file, which is OK, and can be saved -- for now, at least. I have to try to find what I changed in the almost unreadable version, and put that into the older one. Not fun!
Unfortunately, scratch what I said, the reporter opened another report that the issue's back. I'll be following up with them to see if there's any chance to have this bug reliably reproduced.
not confirmed > normal
Severity is still critical, regardless whether the bug is confirmed or not. If it's set to normal, that decreases the chances of getting the bug triaged and fixed. Unfortunately QA is stuck with this bug, hence the keyword needsDevAdvice. Anyway, it can be set to NEW based on the other very similar bug reports. Also setting to high/critical.
https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg Critical is for core functions, major for particular docs. I'll set to Needinfo because new info is needed to fix this, New doesn't help. I kindly ask Mark to use procdump all the time in order to get a dump. Procdump is part of free and useful Sysinternaly Suite. It can be run manually after LO start or better via simple batch file I'll attach now, that is used instead of LO icon to start LO. Dump is then analyzed with https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg . If you can't do it yourself, just upload dump somewhere (if more that 10 MB and can fit here.)
Created attachment 129814 [details] Batch to start LO with procdump
(In reply to Timur from comment #24) > https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart. > jpg > Critical is for core functions, major for particular docs. That's not how I read it. Broken core functions is INCLUDED in that definition as ONE example. If you want to change the definition, we have to discuss is and then clarify that flowchart AND re-prioritize everything.
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 INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/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 MassPing-NeedInfo-Ping-20170628
I have version 5.3.3.2 and the problem has gone away. Thanks for your help, but you can close this now.
That's good to hear. Feel free to set the status to RESOLVED / WORKSFORME in such case.
I think it was already set to those, but I set them so again, anyway. Thanks again.