CPU Frequency Monitor memory leak

CwF · 2019-03-18 15:50:53

I created a panel with 3 instances of CPU Frequency Monitor plugin, min, average, max. I typically have this on a hypervisor, and it had and is working fine on a debian stretch machine, While testing Debian Buster on bare metal I added this same panel, works fine, told me things, then with a few days run time the 3 processes grow from <20MB use to >180MB. The entry 'average' seems to grow the fastest with 'max' close behind. On its 5th day today the memory usage is 20,180,120. That's a little serious memory leak!
Testing is incomplete, and it's occurring on suspect hardware with bios mods, a Q67 chipset and a E3-1200 v1 series cpu. I will now watch this to determine if it's a current buster issue or my hardware. I will watch for it in other test, but wondering if anyone has seen anything like this.

If I edit the properties while the memory usage is high I get one of two results. Either it goes back to a reasonable 15-20MB of usage, or changes it's name to 'wrapper 2.0' and stays high or GROWS.

Last edited by CwF (2019-03-22 13:41:28)

ToZ · 2019-03-18 22:40:55

I've been running three versions on my desktop for about an hour now and don't notice a change (I'm running the latest git versions of all Xfce packages). Which versions of Xfce and specifically xfce4-cpufreq-plugin are you running again? Maybe this has already been fixed (though I don't see any recent memory fixes in the commit logs).

CwF · 2019-03-19 00:16:58

The problem is on Debian's Buster xfce4-cpufreq-plugin 1.2.1-1, the working stretch machine is 1.1.3-1. I don't always use it, related is the install of linux-cpupower which did change the machine behavior some, and I noticed the memory usage. This is a temporary test system, so I will pull that package and give it some run time. Also this is i386, the same machine did well through amd64 test and I did use the setup of min, ave, max on that system too and didn't notice it, but didn't really look. I will delete and move on, but if I see something else I will post back.

Currently still finishing up things, the image is very stable, but in task manager, the min plugin still has its long name and is at 113.6MB, average and maximum have changed to short name 'wrapper-2.0' and are at 122.4 and 206.6MB. Wow, at a 3 day uptime. I do think it needs awhile and some workouts

ToZ · 2019-03-19 01:10:07

If you are seeing a memory leak, then you should definitely create a bug report. It would be helpful if you could get some valgrind debug info to help identify the source.

CwF · 2019-03-19 02:13:56

Fair enough. I'm still learning so it may take some time. The two images will be tested on some more platforms, and I'll add this to the checklist for the coming weeks. If it persist I will document what I can, if the same image does not exhibit the issue on other platforms I'm going to chalk it up to my modded bios on that one machine.

CwF · 2019-03-19 18:33:41

Result

$ tail -30 /tmp/1553018875_valgrind_cpufreq_10.log
--23858-- REDIR: 0x56431d0 (libc.so.6:__memcpy_chk_ssse3) redirected to 0x483ca50 (__memcpy_chk)
--23858-- REDIR: 0x5598760 (libc.so.6:__strrchr_sse2_bsf) redirected to 0x4837660 (rindex)
--23858-- REDIR: 0x56087f0 (libc.so.6:__strcpy_chk) redirected to 0x483c520 (__strcpy_chk)
--23858-- REDIR: 0x5659a30 (libc.so.6:__memcmp_ssse3) redirected to 0x483b0d0 (bcmp)
--23858-- REDIR: 0x5650c30 (libc.so.6:__strncmp_ssse3) redirected to 0x48383f0 (strncmp)
--23858-- REDIR: 0x5588ff0 (libc.so.6:__strncpy_ssse3) redirected to 0x4837eb0 (strncpy)
--23858-- REDIR: 0x55877a0 (libc.so.6:__strcpy_ssse3) redirected to 0x4837cf0 (strcpy)
--23858-- REDIR: 0x5599910 (libc.so.6:__GI_memcmp) redirected to 0x483aef0 (__GI_memcmp)
--23858-- Reading syms from /usr/lib/i386-linux-gnu/gio/modules/libgvfsdbus.so
--23858--    object doesn't have a symbol table
--23858-- Reading syms from /usr/lib/i386-linux-gnu/gvfs/libgvfscommon.so
--23858--    object doesn't have a symbol table
--23858-- REDIR: 0x559a4e0 (libc.so.6:__GI_strspn) redirected to 0x483ce70 (strspn)
--23858-- REDIR: 0x559a370 (libc.so.6:__GI_strcspn) redirected to 0x483cdf0 (__GI_strcspn)
--23858-- REDIR: 0x5598950 (libc.so.6:__memchr_sse2_bsf) redirected to 0x4838f70 (memchr)
--23858-- REDIR: 0x5599c80 (libc.so.6:__GI_memmove) redirected to 0x483bcf0 (__GI_memmove)
--23858-- memcheck GC: 1000 nodes, 597 survivors (59.7%)
--23858-- memcheck GC: 1414 new table size (stepup)
--23858-- memcheck GC: 1414 nodes, 659 survivors (46.6%)
--23858-- memcheck GC: 1435 new table size (driftup)
--23858-- memcheck GC: 1435 nodes, 737 survivors (51.4%)
--23858-- memcheck GC: 2029 new table size (stepup)
--23858-- memcheck GC: 2029 nodes, 829 survivors (40.9%)
--23858-- memcheck GC: 2059 new table size (driftup)
--23858-- memcheck GC: 2059 nodes, 943 survivors (45.8%)
--23858-- memcheck GC: 2089 new table size (driftup)
--23858-- memcheck GC: 2089 nodes, 1021 survivors (48.9%)
--23858-- memcheck GC: 2120 new table size (driftup)
--23858-- memcheck GC: 2120 nodes, 1115 survivors (52.6%)
--23858-- memcheck GC: 2998 new table size (stepup)

Not that I know exactly what I'm looking at...So this i386 image is now configured to log and here from the sandy bridge problem child system. I'm anxious to continue moving back in the time line, next stop a 5600 westmere.

CwF · 2019-03-21 23:23:59

I apologize for using that hack xeon first in my i386-wine creation test, that machine is the problem. I did pop the ssd image in a newer similar E5-1600 and it blew up. So I stuck it in a 5520 chipset 5600 as promised and it rocks. No memory leak. False alarm. Not that any of these machines are appropriate for i386, but for the fun of it.

I unmarked this as solved, it's not, there is a leak. I will create a bug account and try to help. I assume the conversation will continue there, but I need some guidance on how to proceed.

I was able to leave the X58 generation machine running, it leaks too and is now at 45+MB for each process, so it leaks on this platform much slower than the Q67 platform.
As I stated myself, i386 isn't all that appropriate for these generations so I'm unclear about the importance? I made the image for a few reasons, one to assess if i386 offers a smaller footprint than amd64 in a vm, it does. Primarily, to evaluate wine in a non-mixed architecture strictly for 32/16 bit programs. I figured my exploration would go faster on faster machines, it is., As virtio gpu matures I wanted a range of test for this coming to my hypervisor, that is a year out maybe. And last, I intend to try this image on genuine hardware, dual socket P3 tualatins. On that platform this bug will not apply, as it doesn't in a vm.

I'm not aware of any 32bit processors with intentionally and internally variable clock rates?

https://bugzilla.xfce.org/show_bug.cgi?id=15218

Last edited by CwF (2019-03-22 15:03:39)

Xfce Forum

Sub domains

#1 2019-03-18 15:50:53

CPU Frequency Monitor memory leak

#2 2019-03-18 22:40:55

Re: CPU Frequency Monitor memory leak

#3 2019-03-19 00:16:58

Re: CPU Frequency Monitor memory leak

#4 2019-03-19 01:10:07

Re: CPU Frequency Monitor memory leak

#5 2019-03-19 02:13:56

Re: CPU Frequency Monitor memory leak

#6 2019-03-19 18:33:41

Re: CPU Frequency Monitor memory leak

#7 2019-03-21 23:23:59

Re: CPU Frequency Monitor memory leak

Board footer