1)Launch LO. 2)Import the attached file. Actual: LO crashes
Created attachment 96083 [details] Original File
Opening the attached file from the command line, my LibreOffice produces a segmentation fault. I am setting status NEW. Original summary said Windows, so I am leaving platform All. My LibreOffice is master commit 806f4d8, fetched 2014-03-04, configured: --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src built and running on debian-wheezy.
Created attachment 96114 [details] typescript with backtrace with symbols For the benefit of bugzilla search: #0 0x00007fad6b1733f8 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00007fad49df9129 in lcl_InnerCalcLayout (pFrm=0x26e4b40, nBottom=25107, _bOnlyRowsAndCells=false) at /home/terry/lo_hacking/git/libo4/sw/source/core/layout/tabfrm.cxx:1486
Created attachment 114680 [details] console logs + bt with debug symbols (master sources) Just to give an updated bt since I can still reproduce the crash with master sources updated today.
I can no longer reproduce the crash with Version: 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale: es-ES (es_ES) on Windows 7 (64-bit) However, it took around 50 seconds to open the document, so there's still a performance issue present.
With dbgutil version 2015-08-24 running in a chroot environment to debina-sid, the program pegged the CPU for an hour and filled the terminal buffer with messages (line breaks added) ... warn:legacy.osl:28425:1:sw/source/core/layout/flowfrm.cxx:2395: <SwFlowFrm::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied! In the bug summary, I am changing "segfault" to "loop".
Comment on attachment 114680 [details] console logs + bt with debug symbols (master sources) On pc Debian x86-64 with master sources, I got a loop too but no crash
Migrating Whiteboard tags to Keywords: (perf)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I still see the bug in daily Linux dbgutil bibisec repository version 2018-06-13 running on debian-buster. In particular, LO displayed the first page of the document in under a minute, but the screen is still unresponsive and LibreOffice is stil using ~ 100% CPU after 88 CPU minutes.
Still sluggish looping. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 9c5d33e3c9e4a680af61a9e7af8fa73d08b33834 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 28 March 2019
Dear Sourav, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Opening the attached file in a local --dbgutil build of commit feb6fd1f (2021-03-17), built an running on debian-buster, I see: (*) The Writer window quickly shows the top of the document. (*) It is possible to page up and down throught the nine pages of the document with some niticeable delays. (*) CPU usage drops after about 1 min 41 seconds CPU. I think this should qualify for RESOLVED WORKSFORME, but I shall wait for Sourav to comment.
I tried with the latest in Linux 7.2 bibisect repo and the CPU usage won't drop even after several minutes. Note that in general, you should not test performance issues with debug/dbgutil builds, because they include various functionality that affects performance.
@Buovjaga I understand that --enable-dbgutil can cause poorer performance. Is there any way that it can causes better performance? Anyway, I take the loop to be not merely a question of peformance. Meanwhile, all I get is loops, even when I go back and rebuild the version which I reported to open the file successfully. Sigh!
(In reply to Terrence Enger from comment #15) > I understand that --enable-dbgutil can cause poorer performance. Is > there any way that it can causes better performance? I have not heard of such cases
30 sec for opening and full processing in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0ee9501c0b7dc1a291715fff9c1934b1c08cb654 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: threaded
Created attachment 186936 [details] Flamegraph On pc Debian x86-64 with master sources updated today + gen rendering, the file opened quite quickly so I also scrolled until the end of the file and retrieved a Flamegraph.