Summary: | Writer crashes with large file (comment 5 is another bug) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Christian Lehmann <christianw_lehmann> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | buzea.bogdan, lo_bugs, michael.stahl, sdc.blanco, telesto |
Priority: | medium | ||
Version: | 6.3.0.3 rc | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=122792 https://bugs.documentfoundation.org/show_bug.cgi?id=139843 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Attachments: |
bibisect-linux-64-6.3, tail of terminal output
backtrace from master |
Description
Christian Lehmann
2020-09-02 16:04:47 UTC
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 ... |