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?