Overview: When running more than one instance of xfce4-sensors-plugin 1.2.97, one of the processes starts using a lot of CPU (typically >80%) and its readouts freeze after a while. The values shown in the tooltip still update, however. Steps to reproduce: Add two instances of the sensors plugin to the xfce4 panel. Wait a while (may take minutes or hours to manifest). I have updates set for every second; I don't know whether this affects the probability of the bug occurring. Expected result: Both instances should display their assigned sensors and update regularly, while using very little CPU. Actual result: After a while, one instance will start using a lot of CPU and stop updating its readouts. Longer description: I run two instances of the plugin in order to allow temperatures to be displayed using bars by one instance and fan rpm to be shown on tachos by the other. With v1.2.6 of the plugin, a tooltip would only ever be displayed by one instance but this didn't worry me too much. On upgrading to 1.2.97, I found that the tooltip now worked for both instances but noticed that, after a while, one of the instances started using most of a core on the CPU. (That's not a massive issue on my main PC, which has 8 really beefy cores, although it does make the fans a bit louder after a while, but my laptop only has two fairly modest cores and the impact on performance and battery life is noticeable.) It seems to be the second instance (the fan tachos in my case) that shows this behaviour. At the same time (probably resulting from the same issue), the readouts stop updating, although the tooltip still works fine. Right-click access to configuration still works and the readouts can be made to update once by "changing" (retyping the same value) the sensor range. Killing the offending process causes it to be reloaded and it resumes working for a period of time, before going off-piste again. Distribution: Gentoo ~amd64 Kernel: 4.10.0 Versions of some modules: (these are the ones that sound relevant to me; if you need others, let me know) libxfce4ui-4.13.1 xfce4-panel-4.12.0 xfce4-sensors-plugin-1.2.97
Hey, sorry to hear that. Nearly perfect bug report. But (un)fortunately I cannot reproduce that. Had update interval of 6 s and lateron changed to 1 s, running several minutes now. Tried to have the same setup as you do; memory and cpu consumption look fine: $ top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND ... 16862 user 20 0 552036 35340 26084 S 0,3 1,1 0:03.42 panel-28-xfce4- 8466 user 20 0 478032 33624 24788 S 0,3 1,1 0:08.57 panel-17-xfce4- ... Can you attach the configuration files of the two instances or at least enumerate the different sensors you used? What versions of Gtk are you using, hddtemp? As first difference, my libxfce4ui is v4.12.1-2 only. If possible, would you mind downgrading? As a workaround, can you try changing the update interval to 6-10 s perhaps? This is what I use regularly.
Created attachment 7031 Config file for first instance Config file for the first instance added, displaying temperatures as bars.
Created attachment 7032 Config file for second instance Config file for second instance added, displaying fan rpm as tachos.
OK, I've added the two config files (I removed the plugin from the panel and re-added it from scratch this morning). I have downgraded libxfce4ui to 4.12.1-r2 as requested, then restarted the X server. GTK+2 version: 2.24.31-r1 GTK+3 version: 3.22.5 I've been logging the plugin's CPU usage since just before 10am GMT with a very quick & dirty shell loop that simply greps 'ps auxw' for the plugin processes once every ten seconds and dumps it with a timestamp to a file. A quick look at the raw data is quite interesting. One of the processes' CPU usage has climbed gradually during the course of the day. It started at a surprisingly-high (for a very fast CPU) 2.5% and has reached about 25.5% (of a core) now (14:50 GMT) and is causing one core to throttle up to 4.7GHz once a second. The memory usage (RSS) of the offending process has also climbed steadily from 27076kB to 77264kB. The other process has stayed at 0.0% CPU (too low to measure) and unchanging memory usage of 23664kB. I'll leave it logging for a while longer to see what happens then wrangle the messy log file into something a bit more meaningful. (I left the sample rate at 1 per second for the time being to help "trigger" the issue more quickly. Once I've stopped the logging session, I'll change the interval to 10s then see if the same thing happens but more slowly.)
OK, thanks, it seems you are using the libsensors/lmsensors for both instances. Previosly, I had one instance with hddtemp or ACPI configured; this made the difference as I can now reproduce the behaviour. To me it seems it is the "bar" instance, btw. With many (all) available sensors, I made the plugin consume 100% cpu within minutes. Restarting the panel, quickly removing some sensors, you end up with some 7 to 35 % usage; and then you can increase the update interval; the cpu usage sinks down to 3% or less. Similarly, you can change to text or tacho view. It's interesting to see that this doesn't happen with my badly coded text panel and my custom Gtk widget. So, libsensors is not the culprit; libxfce4ui isn't either. I will investigate further.
Hm, interesting. You're right - it is the bars instance that's eating CPU and RAM. I had assumed (without checking) that it was the tachos because that was the instance that was not updating its display, but that must be a separate issue. I'll dig into it a bit more and maybe file a new bug for it. Unfortunately, there are no sensors listed under ACPI and the k10temp sensor is wildly inaccurate (it's reading 1.8°C right now...) so that workaround isn't available :(
The bars use css providers; maybe I need to free or reuse them; unreferencing them doesn't seem to suffice in all cases. See https://bugzilla.xfce.org/show_bug.cgi?id=12975#c7 for example and the lateron linked patches.
Fixed with commit fb3f4be. Many thanks for the indication and help in investigating.