Description: Full error message: https://i.ibb.co/wMMWFZb/Screenshot.png This is a cryptic and randomly occuring error during saving of a very large file such as this one: https://e.pcloud.link/publink/show?code=XZ3HbMZkhqcJb4FaEYynogog19YOYxEj9rk My system info: https://pastebin.com/raw/UYaX8cnC Running on Linux Mint 21.3, have more than 10GB RAM available when error happens. Steps to Reproduce: 1. Download the large ODT file 2. Ctr+S, wait for the progress bar to reach the end 3. Get the popup error message Actual Results: Both the file as well as the file backup (bak file) fail to save. Expected Results: Saving the file as usual. Reproducible: Always User Profile Reset: Yes Additional Info: 1) Issue does not go away when saving in Safe Mode. 2) Same issue happens with autosave, and you get locked out of reading and editing your document because it keeps retrying to save it and failing each time. 3) I have spent 5 hours trying to reproduce the issue with a simpler file without success. One thing I've done is save each chapter as a separate file and then trying to copy-paste each chapter to an empty document, one at a time, and saving the document after pasting each chapter. Issue comes back randomly, does not seem to be tied to a specific chapter or object in the document. 4) Writer seems to have trouble keeping some image files at the bottom of the pages inside the text boundaries as you can see (I will report that separately with a simpler example file), but that does not seem to be the source of the issue, as I am able to manually add newlines until the images are positioned correctly in the next page, then remove the newlines before saving, but the error does not go away. 5) I am suspecting that there are some identically named objects in the document after I have copy pasted content from another document causing this error, but I am unable to verify this. If that were the case then I would have been able to save the document with that content in the previous session somehow.
ODT file link seems to not be response. Try this instead: https://e.pcloud.link/publink/show?code=kZNLbMZj1GOFeIH9B0aRB8xEPajtSeDXiPV
and no the ODT file is not password protected, pCloud is being annoying here
No issue on Windows with: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded It is a huge file with more than four thousand images.
Are you just giving info about the file for others or making a point? I have other documents with >10K images that work fine. This document isn't even 40% done. I don't see anything unreasonable here.
I gave a try on pc Debian x86-64 with master sources updated today and it seems a bit stuck (or need even more time) exported styles (at about 90% of the save): part of bt taken at random: #5 0x00007f64df5d2e36 in SwXMLTableFrameFormatsSort_Impl::AddRow(SwFrameFormat&, std::basic_string_view<char16_t, std::char_traits<char16_t> >, unsigned int) (this=0x7ffd6e694908, rFrameFormat=..., rNamePrefix=u"Table12", nLine=38) at /home/julien/lo/libreoffice/sw/source/filter/xml/xmltble.cxx:302 #6 0x00007f64df5d4c18 in SwXMLExport::ExportTableLinesAutoStyles(SwTableLines const&, unsigned int, unsigned int, std::basic_string_view<char16_t, std::char_traits<char16_t> >, SwXMLTableColumnsSortByWidth_Impl&, SwXMLTableFrameFormatsSort_Impl&, SwXMLTableFrameFormatsSort_Impl&, SwXMLTableInfo_Impl&, bool) (this=0x55c04e95a8f0, rLines=..., nAbsWidth=6034, nBaseWidth=0, rNamePrefix=u"Table12", rExpCols=..., rExpRows=..., rExpCells=..., rTableInfo=..., bTop=true) at /home/julien/lo/libreoffice/sw/source/filter/xml/xmltble.cxx:665 #7 0x00007f64df5d5f92 in SwXMLExport::ExportTableAutoStyles(SwTableNode const&) (this=0x55c04e95a8f0, rTableNd=...) at /home/julien/lo/libreoffice/sw/source/filter/xml/xmltble.cxx:779 #8 0x00007f64df5d8ad1 in SwXMLTextParagraphExport::exportTableAutoStyles() (this=0x55c084b02070) at /home/julien/lo/libreoffice/sw/source/filter/xml/xmltble.cxx:1178 #9 0x00007f6516dab931 in XMLTextParagraphExport::exportTextAutoStyles() (this=0x55c084b02070) at /home/julien/lo/libreoffice/xmloff/source/text/txtparae.cxx:3845 #10 0x00007f64df5a855c in SwXMLExport::ExportAutoStyles_() (this=0x55c04e95a8f0) at /home/julien/lo/libreoffice/sw/source/filter/xml/xmlfmte.cxx:266 #11 0x00007f6516860189 in SvXMLExport::ImplExportAutoStyles() (this=0x55c04e95a8f0) at /home/julien/lo/libreoffice/xmloff/source/core/xmlexp.cxx:1122 #12 0x00007f6516861c9a in SvXMLExport::exportDoc(xmloff::token::XMLTokenEnum) (this=0x55c04e95a8f0, eClass=xmloff::token::XML_TEXT) at /home/julien/lo/libreoffice/xmloff/source/core/xmlexp.cxx:1388 #13 0x00007f64df58fb3e in SwXMLExport::exportDoc(xmloff::token::XMLTokenEnum) (this=0x55c04e95a8f0, eClass=xmloff::token::XML_TEXT) at /home/julien/lo/libreoffice/sw/source/filter/xml/xmlexp.cxx:285 #14 0x00007f651685d373 in SvXMLExport::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x55c04e95a8f0, aDescriptor=empty uno::Sequence) at /home/julien/lo/libreoffice/xmloff/source/core/xmlexp.cxx:814 Remark: I use a local build with enable-dbgutil option which slows down LO (it's the "price" to pay to have max info during debug session when there's a crash or something else). Considering the filesize, I suppose it could be relevant to rather use a master document with subdocuments (see https://help.libreoffice.org/latest/en-US/text/swriter/guide/globaldoc.html?&DbPAR=SHARED&System=UNIX)
We could have a discussion of pros and cons of separate documents, but at the end of the day this error shows up randomly and makes the document not only not saveable, but also frozen as soon as autosave kicks in and gets stuck in a loop retrying to save. So if you've added many pages to such a document, you won't even be able to copy-paste that work to another document since autosave in such a case freezes the editor, at least on Linux. So pages/hours of work will essentially be lost. Also note that due to the size of the file, moving ~20 chapters to separate files will take over 2 hours of work, something frustrating enough that may shy away a user from using LO completely, we don't want that. So I don't think this is a minor bug that can be easily avoided and affects very niche types of documents: user won't know about the issue until it happens and when it happens it can't be stopped and work rescued. For reference, I've produced five such >400 page >10K image documents before the error showed up with this specific document, haven't had much of an issue using LO for such large research documents before.
I tried on a different PC using the exact same OS, LibreOffice version, same SSD model, same RAM capacity and lower CPU specs, and the copied file didn't show an error when saving. But as mentioned, saving the file in Safe Mode on the original PC still causes the same error, rulling out the possibility that the error is due corrupt user profile folders. What else should I check?
Issue is still present on my end. I tried moving the "user" folder ("/home/pc/.var/app/org.libreoffice.LibreOffice/config/libreoffice/4") to a different location and having LibreOffice generate a new one in its place. The issue remained, so it's not related to a corrupt user folder. However as mentioned, the issue is not present with the same file on another PC with inferior specs, so it may still be a corrupt file issue, just not a file in the user folder. What should I check?
(In reply to rgz92 from comment #8) > However as > mentioned, the issue is not present with the same file on another PC with > inferior specs, so it may still be a corrupt file issue, just not a file in > the user folder. What should I check? Maybe keep an eye on memory use while editing the file? Some related reports, showing the issue has been popping up on and off over the years: - bug 60769 - bug 109049 - bug 112235 - bug 157994 seems to point to a RAM issue In any case, pCoud link does not work anymore, and pastebin link neither. I think we should consolidate into bug 157994. *** This bug has been marked as a duplicate of bug 157994 ***
Sorry but this is not a duplicate of your linked issue reports. Here's an updated pCloud link: https://e.pcloud.link/publink/show?code=XZbuIMZ9y6C4uMPwEBVewAsfftoXzAFXQOy And system specs: https://pastebin.com/9xmfjquH As I've mentioned, the error message states: "WriterError. Error in writing sub-document SfxBaseModel::storeShelf: 0x70c23(Error Area:SwClass:Write Code:35) arg1=content.xml at /run/build/libreoffice/sfx2/source/doc/sfxbasemodel.cxx1732.", while in your linked posts the error message is different and states: "Could not save document, error in writing sub document context.xml". I've been able to reproduce your referenced error message by physically replacing my RAM from 32GB to 8GB and it indeed seems to happen due to running out of memory. However my error message in this bug #160892 happens when there's still over 10GB of RAM available during the saving process. As I've mentioned before, the error message happens on one PC with same RAM capacity, but not another one. However, deleting the user folder or running in Safe Mode on the problematic PC does not resolve the problem. So my best guess is there is some data in a file external to both the user folder and the ODT file itself that is used by Writer when saving, which causes the issue, and which is different between the two PCs (one has a corrupt file?). However I don't know what files to look for. I've uninstallled and reinstalled LO but it seems like there are some files left in the system besides the user folder that are not overwritten and are reused when reinstalling.
Please don't set your own report to "new". Someone else has to confirm the issue. (In reply to rgz92 from comment #10) > Sorry but this is not a duplicate of your linked issue reports. > As I've mentioned, the error message states: "WriterError. Error in writing > sub-document SfxBaseModel::storeShelf: 0x70c23(Error Area:SwClass:Write > Code:35) arg1=content.xml at > /run/build/libreoffice/sfx2/source/doc/sfxbasemodel.cxx1732.", while in your > linked posts the error message is different and states: "Could not save > document, error in writing sub document context.xml". Bug 157994 comment 12's attachment 192848 [details] shows the same message as yours (although it's not from the original reporter). I tested with your comment 10 file and could not reproduce on Ubuntu 22.04 with: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Takes a while to save, but no error message. Let's see if someone else can reproduce.
I've verified that the issue does NOT happen with AppImage and Ubuntu PPA versions, only the official Flatpak Flathub version. For reference, cloud storage has nothing to do with this issue, also happens in local folders. Here's an updated link to the file. Test with latest Flathub Flatpak version: https://e.pcloud.link/publink/show?code=kZrtGgZkPsQ9Cee4aLfOpx8Y5Gd04kRNqzk
Bug 162452 is unrelated. Happens also when the file is in a local folder.