[Xfce-bugs] [Bug 16640] New: xfce4-panel: Memory leak in panel plugin wrapper
bugzilla-daemon at xfce.org
bugzilla-daemon at xfce.org
Sun Apr 5 23:36:34 CEST 2020
https://bugzilla.xfce.org/show_bug.cgi?id=16640
Bug ID: 16640
Summary: xfce4-panel: Memory leak in panel plugin wrapper
Classification: Xfce Core
Product: Xfce4-panel
Version: Unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: Medium
Component: Libxfce4panel
Assignee: xfce-bugs at xfce.org
Reporter: BenWiederhake.GitHub at gmx.de
Target Milestone: Panel 4.14
Created attachment 9675
--> https://bugzilla.xfce.org/attachment.cgi?id=9675&action=edit
Fixes the memory leak in the panel wrapper
Hello,
tl;dr: The wrapper leaks 32 bytes with every redraw event.
On my system, that means I have to reboot every other week.
First I want to convince you that there actually is an issue.
For that, I replaced /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 by a
little script that usually exec's the real binary, but intercepts cpugraph, and
calls it through valgrind. This way I could see what the wrapper does under
"real" circumstances.
Here is the relevant valgrind log output, for xfce4-panel in Debian's version
4.14.3-1 with cpugraph-plugin on "Very fast (250ms)",
killing after 1 hour:
==7077== 414,560 bytes in 12,955 blocks are definitely lost in loss record
6,679 of 6,679
==7077== at 0x48367F3: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==7077== by 0x544D1C8: g_malloc (gmem.c:102)
==7077== by 0x54651F1: g_slice_alloc (gslice.c:1024)
==7077== by 0x5465851: g_slice_copy (gslice.c:1075)
==7077== by 0x5390AAF: boxed_proxy_lcopy_value (gboxed.c:267)
==7077== by 0x4B4F530: gtk_style_context_get_valist (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==7077== by 0x4B4F759: gtk_style_context_get (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==7077== by 0x10CCA2: wrapper_plug_draw (wrapper-plug.c:221)
==7077== by 0x4BF2813: ??? (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==7077== by 0x4BFB9AF: ??? (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==7077== by 0x4AA9C93: gtk_main_do_event (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==7077== by 0x4F99804: ??? (in
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.2404.10)
==7077==
==7077== LEAK SUMMARY:
==7077== definitely lost: 415,048 bytes in 12,988 blocks
==7077== indirectly lost: 0 bytes in 0 blocks
==7077== possibly lost: 4,720 bytes in 47 blocks
==7077== still reachable: 1,561,423 bytes in 16,581 blocks
==7077== of which reachable via heuristic:
==7077== length64 : 4,744 bytes in 82 blocks
==7077== newarray : 2,160 bytes in 55 blocks
==7077== suppressed: 0 bytes in 0 blocks
==7077== Reachable blocks (those to which a pointer was found) are not shown.
==7077== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==7077==
==7077== ERROR SUMMARY: 40 errors from 40 contexts (suppressed: 0 from 0)
That's about 70 MB per week:
https://www.wolframalpha.com/input/?i=414560+byte+*+week+%2F+hour
That matches my observations about cpugraph needing more and more memory.
wrapper-plug.c:221 (in the old version; the line number has changed since then)
fetches the background color, and from the stacktrace it looks like a copy is
made, and the caller is supposed to clean up that copy. However, wrapper-plug
does not do that.
Note that sizeof(GdkRGBA)==32 and 414560.0 / 12955.0 == 32.0, so it's
plausible.
The latest version doesn't change this behavior; this makes sense because
wrapper-plug.c didn't change significantly.
Here's the result after running for 10 minutes:
==6308== 65,952 bytes in 2,061 blocks are definitely lost in loss record 6,456
of 6,459
==6308== at 0x48367F3: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==6308== by 0x544F1C8: g_malloc (gmem.c:102)
==6308== by 0x54671F1: g_slice_alloc (gslice.c:1024)
==6308== by 0x5467851: g_slice_copy (gslice.c:1075)
==6308== by 0x5392AAF: boxed_proxy_lcopy_value (gboxed.c:267)
==6308== by 0x4B51530: gtk_style_context_get_valist (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==6308== by 0x4B51759: gtk_style_context_get (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==6308== by 0x10CCC2: wrapper_plug_draw (wrapper-plug.c:190)
==6308== by 0x4BF4813: ??? (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==6308== by 0x4BFD9AF: ??? (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==6308== by 0x4AABC93: gtk_main_do_event (in
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.10)
==6308== by 0x4F9B804: ??? (in
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.2404.10)
==6308==
==6308== LEAK SUMMARY:
==6308== definitely lost: 66,095 bytes in 2,069 blocks
==6308== indirectly lost: 0 bytes in 0 blocks
==6308== possibly lost: 4,696 bytes in 47 blocks
==6308== still reachable: 1,544,097 bytes in 16,302 blocks
==6308== of which reachable via heuristic:
==6308== length64 : 4,384 bytes in 76 blocks
==6308== newarray : 2,144 bytes in 54 blocks
==6308== suppressed: 0 bytes in 0 blocks
==6308== Reachable blocks (those to which a pointer was found) are not shown.
==6308== To see them, rerun with: --leak-check=full --show-leak-kinds=all
Freeing the GdkRGBA causes no problems and fixes the leak. This is with the
patch, after 10 minutes:
==5086== LEAK SUMMARY:
==5086== definitely lost: 143 bytes in 8 blocks
==5086== indirectly lost: 0 bytes in 0 blocks
==5086== possibly lost: 4,696 bytes in 47 blocks
==5086== still reachable: 1,548,565 bytes in 16,442 blocks
==5086== of which reachable via heuristic:
==5086== length64 : 4,384 bytes in 76 blocks
==5086== newarray : 2,144 bytes in 54 blocks
==5086== suppressed: 0 bytes in 0 blocks
==5086== Reachable blocks (those to which a pointer was found) are not shown.
==5086== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5086==
==5086== ERROR SUMMARY: 39 errors from 39 contexts (suppressed: 0 from 0)
Please find my patch attached.
Cheers,
Ben
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Xfce-bugs
mailing list