Always configured as mentioned, min, ave, max for the 3 instances, either in a isolated panel or combined with others.
On startup typical is around 20 MB usage.
On a particular i386 Debian Buster image current as of week 7 this year, was created in a kvm vm and qemu-img'd to a ssd and tested in various hardware. In the VM the plugin is not used. I enable a panel with the plugin when on real hardware.
On an intel Q67 (C602 I believe) with a E3-1225 v1 Sandy Bridge the leakage starts as seen in the post referenced above. The rate is perhaps 100MB/day.
On a X8DTH-i with currently a E5540, the leakage rate is 20+MB per day.
I mention in the thread, these are inappropriate machines for aa i386 OS, so I don't know...Happy to donate some time anyway.
I did pass through a similar amd64 image and did not notice such leakage, but I wasn't looking for it. That image passed my hardware test for an image enumerating correctly on various hardware, and I wrote over the image with the i386, so I lost the opportunity for the moment to evaluate Buster's state on amd64. I will start testing Buster amd64 hypervisor images soon and will use such a panel with this plugin, I don't intend any amd64 non-hypervisor use on real hardware, and the amd64 is in use on a stretch hypervisor with the panel, and no leaks.
So at the moment, only an issue on buster i386 on the mentioned 64 bit platforms using xfce4-cpufreq-plugin 1.2.1-1 as packaged by Debian Buster.
Created attachment 8468
Yes this bugs me either: on RaspberryPi running 24/7 sessions need restart after few days due to this.
Did some valgrinding (as suggested in https://docs.xfce.org/xfce/xfce4-panel/debugging) with interesting results:
1. I started some valgrind-panel-sessions with default settings of cpufreq-plugin: With Icon / default Font size -> Font was far too big to display all contents. During active valgrind session there are pairs of lines dropped periodically as
| x nodes, y survivors (z%)
| x new table size (stepup)
I watched them passing by and did not see monotonic increase of numbers. They increased but I expected more.
2. Then I modified cpufreq-plugin settings to similar as they are on my Raspi: No Icon / reduce font size so that texts fit into plugin's area without being clipped (in my case Sans 9). Now the increase turned straighter (see file 8468 above - search for 'new table size').
3. Continued with this and that an then stopped xfce-panel. This causes valgrind to create the final bill (scroll to end of file). The main memory leak (last in file I skipped the others to reduce size - was 7.3MB): is in
cpufreq_update_plugin -> cpufreq_label_set_font -> gtk_css_provider_load_from_data
Questions (am not a GTK expert) which can lead to a fix
1. Is there some cleanup for parameters in gtk_css_provider_load_from_data required?
2. This might just reduce leak but: Is it necessary to call cpufreq_label_set_font on each cpufreq_update_plugin? The font size is fixed by configuration
Hope this helps
Created attachment 8492
Patch attached should do
@Clark If it's going to make upstream, I understood you correctly and you are still willing to donate I suggest to send to Xfce Foundation e.V - they are the heros making this fantastic desktop.
Very good, thank you.
-- GitLab Migration Automatic Message --
This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/panel-plugins/xfce4-cpufreq-plugin/-/issues/3.
Please create an account or use an existing account on one of our supported OAuth providers.
If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests
Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev