Expected behavior: reasonable memory usage. Actual behavior: I see it using >490 MiB of memory, after 37 days, using 3 second update intervals. This is related to #3064, #6539, #6431, and probably all of the results when you search for "memory" with the xfce4-sensors-plugin "product". In the referenced bug reports, you complain (rightfully so) about not knowing where the memory went. I don't quite know how to help you, but here's a compressed coredump of the process: https://www.dropbox.com/s/f4n20l0tyf4cbxd/xfce-sensors-plugin.gcore.3360.bz2?dl=0 WARNING: compressed size: 20M; uncompressed size: 636M. While generating the core dump I got a bunch of errors, so I'm not sure in how far this is usable anymore: https://www.dropbox.com/s/gycz3y100hdaerp/xfce-sensors-plugin.errors.txt?dl=0 (Hosted on Dropbox, as the error log doesn't make sense without the coredump anyway.) (The errors are mostly due to library-updates after xfce4-sensors-plugin started, so gcore and xfce4-sensors-plugin see different versions of the same library.) As the process is still running on my machine, and I can reliably (albeit slowly) reproduce the issue, I'm willing and able to give additional information, I just need to be told what to run. And just in case it's relevant, here's what `top` said shortly before I did the coredump: VIRT ~635660K RES ~491176K SHR ~8320K Regards, Ben
Created attachment 6875 Prevent memory leak on show_units==true
A significant portion of the coredump (and therefore memory) seems to look like this: 000F5550 00 00 00 00 00 00 00 00 C1 00 00 00 00 00 00 00 3C 73 70 61 6E 20 66 6F ................<span fo 000F5568 72 65 67 72 6F 75 6E 64 3D 22 23 30 30 42 30 30 30 22 20 73 69 7A 65 3D reground="#00B000" size= 000F5580 22 6D 65 64 69 75 6D 22 3E 33 30 20 C2 B0 43 3C 2F 73 70 61 6E 3E 20 20 "medium">30 ..C</span> 000F5598 3C 73 70 61 6E 20 66 6F 72 65 67 72 6F 75 6E 64 3D 22 23 30 30 42 30 30 <span foreground="#00B00 000F55B0 30 22 20 73 69 7A 65 3D 22 6D 65 64 69 75 6D 22 3E 32 30 20 C2 B0 43 3C 0" size="medium">20 ..C< 000F55C8 2F 73 70 61 6E 3E 20 20 3C 73 70 61 6E 20 66 6F 72 65 67 72 6F 75 6E 64 /span> <span foreground 000F55E0 3D 22 23 42 30 30 30 42 30 22 20 73 69 7A 65 3D 22 6D 65 64 69 75 6D 22 ="#B000B0" size="medium" 000F55F8 3E 32 39 20 C2 B0 43 3C 2F 73 70 61 6E 3E 20 20 00 00 00 00 00 00 00 00 >29 ..C</span> ........ 000F5610 2F 73 70 61 6E 3E 20 20 81 00 00 00 00 00 00 00 3C 73 70 61 6E 20 66 6F /span> ........<span fo This looks like the HTML version of the displayed string in my case. While scrolling through the source, I found in /panel-plugin/sensors-plugin.c:640 (re-indented) if (sensors->show_units) { tmpstring = g_strconcat (myLabelText, "<span foreground=\"", chipfeature->color, "\" size=\"", sensors->font_size, "\">", chipfeature->formatted_value, NULL); myLabelText = g_strconcat (tmpstring, "</span>", NULL); g_free (tmpstring); } The assignment to `myLabelText` looks smelly to me. Doesn't this lose the pointer originally stored in `myLabelText`? If that is really all there is, please see the above patch.
Great, thanks for investigations, will have to look, the string might already have been freed before, there were some issues in previous versions or during development.
Works as intended for me. This is how I tested it: $ # Install patched version $ pidof xfce4-sensors-plugin 17262 $ while true; do date; cat /proc/17262/status | grep -E "VmSize|RSS"; sleep 600; done > sizes.log ^C $ kill 17262 $ # Downgrade again to "current" version $ pidof xfce4-sensors-plugin 18834 $ while true; do date; cat /proc/18834/status | grep -E "VmSize|RSS"; sleep 600; done > sizes_old.log ^C $ Please find sizes.log and sizes_old.log attached. Note that the patched version's memory consumption doesn't increase over time, in contrast to the current git version. The difference in *initial* runtime memory consumption could be due to debugging symbols and differing build configuration.
Created attachment 6876 Empirical evidence that it works (patched memory consumption)
Created attachment 6877 Empirical evidence that it works (*UN*patched memory consumption)
thanks again, the call to gfree() really was forgotten although it existed in all the other nearby pathes.