Description: Everything is fine after a save, one core cpu stucks 100%. If I click on Save as, CPU goes down until I validate. LO saves the file and CPU goes up again. If I close the file, and keep LO opened, CPU goes down. If I open this file again, CPU goes up. Bug works on another computer with LO 5.2 on linux with the same file. OpenGl desactivated example of few line of strace : 4755 13:42:13.982038 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) 4755 13:42:13.982074 poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 2, 2997) = 1 ([{fd=11, revents=POLLIN}]) 4755 13:42:15.902936 recvmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\6\0\267\7\374'\206\0F\1\0\0@\0@\4\0\0\0\0\324\3\"\3\324\3\n\3\20 \1\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 4755 13:42:15.903103 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) 4755 13:42:15.903322 poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}]) 4755 13:42:15.903396 writev(11, [{iov_base="&\3\2\0@\0@\4", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8 4755 13:42:15.903457 poll([{fd=11, events=POLLIN}], 1, -1) = 1 ([{fd=11, revents=POLLIN}]) 4755 13:42:15.903497 recvmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\1\270\7\0\0\0\0F\1\0\0\0\0\0\0\324\3\"\3\324\3\n\3\20 \0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 4755 13:42:15.903543 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) 4755 13:42:15.903617 poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}]) 4755 13:42:15.903675 writev(11, [{iov_base="&\3\2\0@\0@\4", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8 4755 13:42:15.903739 poll([{fd=11, events=POLLIN}], 1, -1) = 1 ([{fd=11, revents=POLLIN}]) 4755 13:42:15.903797 recvmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\1\271\7\0\0\0\0F\1\0\0\0\0\0\0\324\3\"\3\324\3\n\3\20 \0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 How could I sent you the complete log ? Thanks Steps to Reproduce: 1.open a file 2. LO saves the file 3. working with file 4. one core cpu uses 100% 5. Core goes down as soon as I close only this file Actual Results: I could work on the file, save it again but CPU goes up Expected Results: normal use instead of increasing use cpu Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 137619 [details] strace log
Does the same happen with a fresh master build? http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/ https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Yes it does. Something really weird happens. I could not figure out how it goes and how it comes away. I work all day long from the same file. Now I added few pages and correct previous pages. I recorded many times in the same file and three times through a new file name. So few new files were created. All day long one CPU stucks 100%. At the end of the day, it stopped. This occurs 3 times during the four last days. Each times the CPU goes up after I save the file. During each save process CPU goes up and sometimes it stays stucked. I will record a strace log with a good file and deposit here. May be difference could be helpfull.
Created attachment 137732 [details] strace log of a correct file strace log of a file I currently work with under normal CPU use.
I am sorry. I forgot to mention that my both previous messages describe something I observed with 5.4.2.2. release. I only tested bad file during few seconds with fresh master dev libreoffice and CPU also goes up. I hope this makes clearer.
Do you get the 100% CPU with a completely blank, new file?
No the new file (a save from an old one) is working perfectly. All the file work, I could edit them, and save them but with one core CPU 100%. After my message on the 2017-11-14 02:00:57 UTC, one hour later CPU goes up again and this time I was not saving the file.
To test, we would need you to attach such a problematic file. I hope you can share some version of it in public.
I have probably solved the issue but I ignore the technical reason. Because I could not yet publicy my work (PhD thesis), I worked around to cut part of the text and to save the file. If the file would be still problematic I would post it. Test 1 I cut third part of the text; save ; cpu 100% I update index ; save ; cpu goes down !! Test 2 I tried again with a problematic file. I did not cutt off any parts. I just updated index without saving; cpu goes down ! I conclude the bug is linked to index and updating process of index. I will try to cutt away big part of the work and to sent the file if CPU issue comes again. Would you be helpfull to sent you strace log during the updating index process of a problematic file ?
I guess the logs so far are fine (I'm not an expert on them). Maybe you could try creating a version of the file that is sanitized: https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission#Sanitize_file_text That page has a tip on replacing all text with "x" letters.
Created attachment 137750 [details] problematic file sanitized problematic copy of problematic file.
(In reply to RGlibreOffice from comment #11) > Created attachment 137750 [details] > problematic file sanitized > > problematic copy of problematic file. CPU does not get stuck at 100% with save, but on open it complains I don't have these linked files: analyse des données/tableau projet rencontre faire.ods Images pour rédaction thèse/schéma_S6_SC34b.odg What if you break the links in the sanitized document and try to save? Does it still get stuck at 100% upon saving? Tested with Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: d73225119476de1826f648acca9e93bf6797e813 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 12th 2017
yes I have tested on another computer where pics and drawing are not copied so all links were broken; and CPU was 100%. My message on 2017-11-08 19:14:05 UTC has mentionned that I have tested on another computer which is ubuntu 16:10 My working computer is on manjaro 4.13.12-1 Version: 5.4.2.2.0+ Build ID: 5.4.2-2 Threads CPU : 4; OS : Linux 4.13; UI Render : par défaut; VCL : gtk2; Locale : fr-FR (fr_FR.utf8); Calc: single
Now I solved the mystery: I used kde4 VCL plugin, so I did not see the 100% CPU. When I launched with SAL_USE_VCLPLUGIN=gtk libreoffice or SAL_USE_VCLPLUGIN=gtk3 libreoffice CPU was already stuck at 100% after opening. It continued after saving. VCL plugin "gen" did not have the problem. Version 3.6.7 with gtk2 did not show the problem, so maybe it can be bibisected.
ok and what about the relation with index updating. Have you try it to reproduce?
(In reply to RGlibreOffice from comment #15) > ok and what about the relation with index updating. > > Have you try it to reproduce? Well I will leave it to some developer to look into.
I tested the problematic file under vlc=gen, it did not solve the problem. I got same issue. The only thing works for me is to update index of the odt file. I did not try vlc=kde4 test 3 Version: 5.4.2.2.0+ Build ID: 5.4.2-2 Threads CPU : 4; OS : Linux 4.13; UI Render : par défaut; VCL : x11; Locale : fr-FR (fr_FR.utf8); Calc: single CPU goes up until I updated index table. Is there a way to install only vlc=kde4 on xfce archlinux install without installing all kde environement ? I am sorry to ask this here! No problem if I won't get any help.
Weird, as gen worked for me. Can you copy and paste here the exact command line command you give to launch with gen? I want to double-check.
(In reply to Buovjaga from comment #18) > Weird, as gen worked for me. Can you copy and paste here the exact command > line command you give to launch with gen? I want to double-check. I do not use a command line. I have edit /etc/profile.d/libreoffice-gtk2.sh and /etc/profile.d/libreoffice-gtk2.csh as : # to force a certain look'n feel export SAL_USE_VCLPLUGIN=gen #export SAL_USE_VCLPLUGIN=kde4 #export SAL_USE_VCLPLUGIN=gtk #export SAL_USE_VCLPLUGIN=gtk3 # currently broken and not available
Problem not yet seen in latest commit of Linux 50max bibisect repo
Created attachment 150876 [details] Perf flamegraph Took it from file opening. If I don't exit after fileopen, CPU stays at 100% Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1fee3f1da6291bfbcd75455512726215d41b3e83 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 18 April 2019
This is a writer layout loop issue. I can see the layout running in the idle handler, and it never terminates, which is a not uncommon problem with writer's layout. No idea how to fix it, however.
Bibisected with win 5.1 repo to https://git.libreoffice.org/core/+/48c2815dd20cf20eeec8bb4e003000f4a3d13291%5E!/ Same idle handling thing as bug 119840
Dear RGlibreOffice, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug