Description: Writer crashes with large file I had earlier (January 2019) submitted the odt file I have been working on for the past years, using various versions of LO 6 and now LO 7 and with various Ubuntu 18.04 desktops, including Unity, KDE, Openbox and now Ubuntu default. In all of these configurations, I have been confronted with repeated freezes of LO. I cannot count how many of the automatic crash reports I have released over the years. The situation has not improved in the least. There is no particular action within LO Writer that conditions the freeze. Sometimes it freezes when left alone. Ubuntu then sometimes pops up a message saying that LO is not responding, leaving me with the choice of stopping the task or waiting. If I stop it, what follows runs as expected. If I choose ‘Wait’, then the entire Linux session freezes, and I have to restart the computer. I have 8 GB RAM and a hard disk drive with sufficient free space for virtual memory. The odt file (an earlier version of which you have; see above) is now 1,2 MiB in its packed form and 12,6 MiB if unpacked (fodt). As far as I can tell, there are two possible sources for the regular breakdowns: 1) The fodt file is way too large because there is insufficient formatting management. For instance, I can see many redundancies in it: A paragraph template is specified for all italics, and some word contained in it is specified for italics, in addition. This happens because strings are copied including their formatting information without respecting the target context, a bug that I reported long ago. And there are many more redundancies and inconsistencies. If LO cannot avoid the creation of these while the document is being edited, then it should have a file repair function (do I need to mention MS Office?) which corrects, purifies and condenses a file. 2) The second possible problem is memory management. If loaded into LO Writer, the Ubuntu Task Manager tells me that soffice.bin occupies 612,9 MB “Resident Set Size” and 6,3 GB “Virtual Memory Size”. Without being a specialist in memory allocation, this seems pretty much to me. If LO has the entire machine for itself, it is, nevertheless, usually stable. As soon as other applications (e.g., Thunderbird or Firefox) are running simultaneously, breakdown threatens. Maybe on the basis of all those crash reports sent over the years (should I reveal my IP address?) and the present problem description, someone could take care of this rather serious bug. Steps to Reproduce: 1. Load the file I sent in January 2019. 2. Load other applications. 3. Wait. Actual Results: First LO Writer freezes. Then Ubuntu freezes as specified in the description. Expected Results: Writer should be stable. Reproducible: Always User Profile Reset: No Additional Info: My most recent installation is only a week old. Resetting the profile would not make any difference. There is, in version 7, no 'Use OpenGL' option in the preferences.
Are we talking about the file at bug 122792?
Yes. I can submit the current version of the file if necessary. It would have to be anonymized again. If I receive instructions how to do this, I will do so.
(In reply to Christian Lehmann from comment #2) > Yes. > I can submit the current version of the file if necessary. It would have to > be anonymized again. If I receive instructions how to do this, I will do so. Find & replace CTRL+H Turn on Match case, and regexp: Find: ([bcdfghjklmnpqrstvwyz]) Replace with: x Replace All
Although the following is not a crash, it is yet related to LO's trouble with large files: Writing into such a file gets increasingly tedious. Input text is displayed with enormous latency; I type much faster than the input text appears on the screen (mind you, only in LO, not in any other application). Also, characters are input with a different speed than blank spaces and text cursor movements, so these get intermixed with input text words. These are just more symptoms of the two problems that a) text files are blown up to unreasonable sizes and b) memory management is insufficient.
1. Open attachment 165096 [details] bug 122792 2. CTRL+A 3. CTRL+X 4. CTRL+V -> Crash
Crash with 6.3 No crash on paste with 6.2
Created attachment 165798 [details] bibisect-linux-64-6.3, tail of terminal output Working in bibisect-linux-64-6.3 repository on debian-buster, I find the bug started: commit s-h date -------- -------- ------------------- good 717ce60f 43a7231c 2018-11-15 14:10:06 bad f7287b31 ae246b44 2018-11-15 14:10:06 for which the commit message is commit ae246b44da1708417aaaefe4f9186cfbbb9a9137 Author: Michael Stahl <Michael.Stahl@cib.de> AuthorDate: Wed Nov 7 14:16:28 2018 +0100 Commit: Michael Stahl <Michael.Stahl@cib.de> CommitDate: Thu Nov 15 15:10:06 2018 +0100 sw_redlinehide_3: add second result to SwGetRefField ... and init it in SwGetRefField::UpdateField(). Change-Id: I69af00678e84214d4a122d8b2d940fcdda5f4ccf I waited for CPU usage to return to 0% before each operation. This introduces considerable delay, especially between first rendering of the document and <Ctrl>+A. When I probed the "good" versions, after LibreOffice correctly responded to <Ctrl>+V, I continued with 5. CTRL+Q ALT+D the <Alt>+D being a reponse to the question about saving the document before quitting.) In the probes of versions closest the first bad version, LibreOffice promptly closed the Writer window and then finished normally after about 3 more minutes with 100% CPU. However, two probes of the earliest versions in the repository, upon <Ctrl>+Q <Alt>+D, crashed with a Signal 6. A backtrace from this crash looks quite different from the backtrace from a crash upon <Ctrl>+V. I am removing keyword bibisectRequest and adding bibisected, bisected.
Created attachment 165799 [details] backtrace from master This backtrace is from a local build of commit b42d5557, 2020-09-10, built and running on debian-buster, configured: --with-vendor=Terrence Enger --with-jdk-home=/usr/lib/jvm/default-java --enable-split-debug --enable-gdb-index --enable-ld=gold --enable-option-checking=fatal #--enable-dbgutil --enable-debug --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --without-package-format I am removing keyword wantBacktrace and adding haveBacktrace.
Michael, I add you on CC on this bug.
the scenario of comment #5 and all the subsequent comments relating to it was separately filed as bug 139843 the freeze in the description sounds different, as if there's no specific steps known to cause the freeze. so i'll clean up the issue status here to make it less confusing and set this back to UNCONFIRMED.
everything copied to bug 139843 i can't mark the 2 attachments as obsolete.
(In reply to Michael Stahl (allotropia) from comment #11) > everything copied to bug 139843 > > i can't mark the 2 attachments as obsolete. I have marked the two attachments obsolete. The links to them in bug 139843 comment 9 still work.
I can no longer open a file with over 3000 pages. I am using Windows 10 and Writer just crashes if I try to open the file.
LO 7.2.4.1 on Windows 10: The file I submitted several times before (now 700 pages, 1.788 KB on disk) caused repeated crashes of LO Writer in the past weeks. Every time, I sent an automatic crash report. Apart from the sheer size of the file, which obviously plays a role, the etiology is not easy to pin down, as there seems to be no specific editor operation which triggers it. It appears that this happens (only?) if the same document is open in a second window. If anybody has helpful suggestions how to nail down the cause, I (and others) will be grateful.
I guess this all is about attachment 148801 [details] (just write like that, not "the file from the other bug..) There were different problems but I don't see some testing with LO master 7.4+. I close as WFM. If this file causes crash or hang, please write exact steps to reproduce. If similar but newer/larger file hangs, please attach anonymized, write exact repro steps and set Unconfirmed.
Note that if you get crash, and send automatic crash report, you should write the link here. But link itself will not help without repro steps. As seen in bug report form, "User Profile Reset: " indicates that 1st step should be profile reset or delete (or temp. rename if you customized it, to test).
(In reply to Timur from comment #15) > I guess this all is about attachment 148801 [details] (just write like that, > not "the file from the other bug..) > There were different problems but I don't see some testing with LO master > 7.4+. > I close as WFM. > If this file causes crash or hang, please write exact steps to reproduce. > If similar but newer/larger file hangs, please attach anonymized, write > exact repro steps and set Unconfirmed. Just one remark: It appears that there are crashes which are not reproducible, so "exact steps" cannot be described. I had hoped that the automatic crash reports are good for something. But maybe the only thing that developers can learn from them is that a certain version of LO sometimes crashes ...