Description of problem: When Libreoffice is launched, it uses one full CPU. I need to leave a Libreoffice's window (like "open", "export", or "print") to end the problem. It looks like a gtk3 issue. Here is what I get : (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:32:20: '-gtk-icon-filter' is not a valid property name (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:192:4: unknown syntax for transform (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:499:20: '-gtk-icon-filter' is not a valid property name (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:520:20: '-gtk-icon-filter' is not a valid property name (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:1930:20: '-gtk-icon-filter' is not a valid property name (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:3522:0: unknown syntax for transform (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:3526:0: unknown syntax for transform (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:3530:0: unknown syntax for transform (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:5110:0: unknown syntax for transform (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:5115:0: unknown syntax for transform (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:5487:20: '-gtk-icon-filter' is not a valid property name (soffice:6175): Gtk-WARNING **: Theme parsing error: gtk.css:5795:0: Missing semicolon at end of color definition Version-Release number of selected component (if applicable): Version: 5.3.3.1.0+ Build ID: 5.3.3.1-1.mga6 Threads CPU : 4; Version de l'OS :Linux 4.9; UI Render : par défaut; VCL : gtk3; Moteur de mise en page : nouveau; Locale : fr-FR (fr_FR.UTF-8); Calc: group Processor : skylake Graphical card : Gforce 1060 How reproducible: Steps to Reproduce: 1. open libreoffice 2. open an inside window 3.
Assigning to the registered maintainer, but CC'ing all packagers collectively, in case the maintainer lacks time and another packager can look into this.
CC: (none) => marja11, pkg-bugsSource RPM: (none) => libreofficeAssignee: bugsquad => thierry.vignaud
It is enough to just open LibreOffice main panel. Problem persist when opening i.e writer with or without document. I see it*) in cauldron i586 fresh install three weeks ago and updated, test in MATE, ati graphics. No high CPU use on my workstation cauldron x86_64 upgraded from mga5 a year ago and then kept updated, test in Plasma, Nvidia proprietary driver. *) just observed high CPU, i have not dug for more symptoms. This is an old T43 thinkpad with one CPU and stil useable despite this.
CC: (none) => fri
CC: (none) => wilcal.int
On real hardware, M6, Plasma, 64-bit Confirmed here. Opening any one Libreoffice app maxes out one of the 8 threads. Which thread gets used, and maxed out, is random on launch. Launching Writer, and any other(s) Libreoffice app, at the same time only uses one thread. Opening other Libreoffice apps may switch which thread is being used and maxed out. System Monitor tells me that soffice.bin is the cpu hog. Sometimes when I close all of the Libreoffice apps soffice.bin sticks around and continues to hog 100% of one thread. M5 does not have this problem. Test platform: Intel Core i7-2600K ( 4-cores, 8-threads ) Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB)
Copied from qa-discuss, Glen Ogilvie : > soffice.bin seems to sit at 100% cpu, although works fine. > strace shows repeated: > [pid 8932] poll([{fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}], 3, 409) = 1 ([{fd=9, revents=POLLIN}]) > [pid 8932] read(9, "\1\0\0\0\0\0\0\0", 16) = 8 > [pid 8932] write(9, "\1\0\0\0\0\0\0\0", 8) = 8 > [pid 8932] recvmsg(14, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
Interestingly, it only happens with gtk (both gtk2 & gtk3) SAL_USE_VCLPLUGIN=gtk libreoffice --writer SAL_USE_VCLPLUGIN=gtk3 libreoffice --writer But not with: SAL_USE_VCLPLUGIN=gen libreoffice --writer SAL_USE_VCLPLUGIN=kde4 libreoffice --writer (providing libreoffice-kde4 is installed) Since LO hasn't been updated for one month, I wonder if some other lib upgrade could have caused that
Summary: Libreoffice uses 1 full CPU when launched => Libreoffice uses 1 full CPU when launched (only when using gtk[23])CC: (none) => olav, thierry.vignaud
I'll update to RC2
(In reply to Thierry Vignaud from comment #5) > Since LO hasn't been updated for one month, I wonder if some other lib > upgrade could have caused that By selective update, seems like one of these is the culprit: Transaction ID 591e3317 started erase lib64glib2.0-devel-2.52.1-1.mga6.x86_64: success erase glib2.0-common-2.52.1-1.mga6.x86_64: success erase glib-gettextize-2.52.1-1.mga6.x86_64: success erase lib64gio2.0_0-2.52.1-1.mga6.x86_64: success erase lib64glib2.0_0-2.52.1-1.mga6.x86_64: success install lib64glib2.0_0-2.52.2-1.mga6.x86_64: success install lib64gio2.0_0-2.52.2-1.mga6.x86_64: success install glib2.0-common-2.52.2-1.mga6.x86_64: success install glib-gettextize-2.52.2-1.mga6.x86_64: success install lib64glib2.0-devel-2.52.2-1.mga6.x86_64: success
CC: (none) => mageia
CC: (none) => nelg
Thx for the pickpointing/bisecting
Assignee: thierry.vignaud => olavSource RPM: libreoffice => libreoffice, glib2.0
Should be fixed with glib2.0-2.52.2-2.mga6
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
I confirm problem is gone here :) -after update of glib2 and also libreoffice which apparently received an update some hours before. - have not tested updating only one of them.
Real EFI hardware, Radeon video. Just to confirm that after updating my Mageia 6 system this morning, then investigating the reported problem of 100% CPU with LibreOffice (Write & Draw under Mate & Gnome) - it was not there! glib2.0-common-2.52.2-2.mga6 lib64glib2.0_0-2.52.2-2.mga6 The system update also included LibreOffice: 5.3.3.2-1.mga6.
CC: (none) => lewyssmith
The LO update didn't fix anything. The glib2.0 did. Same as in other distros.