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.
First LO Writer freezes. Then Ubuntu freezes as specified in the description.
Writer should be stable.
User Profile Reset: No
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?
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)
> 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:
Replace with: x
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
4. CTRL+V -> Crash
No crash on paste with
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
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().
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:
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.