Memory leak of battstat-applet

ymollard commented 5 years ago

It seems there's a memory leak in applet battstat-applet when it runs for a couple of days with several standby cycles.

The only thing I've identified so far is the battstat-applet process eating 1.9GB of RAM in Mate monitor. When this bug occurs, the actual battery icon disappears from the notification bar.

battstat

This is Mate 1.20.1, this version is bundled with Ubuntu 18.04.1. I can perform some more tests and try new versions of applets but would need some input on the procedure. Ideally I'd like to test temporarily without installing new versions, in order to prevent conflicts during future system updates.

jackBzzz commented 5 years ago

Ubuntu Mate 18.04.1 - leak still happening after a few days of uptime. Probably same issue as #298 and #225 Almost two years old...

ymollard commented 5 years ago

Dear contributors @sbalneav, @monsta, @stefano-k, @vkareh, @szesch, @perberos, @infirit, would you mind giving a hand about that topic?

jackBzzz commented 5 years ago

Tried today to compile the applets from source in debug mode. No luck, same issue as @thanatos in #225 configure: error: Package requirements (libmatepanelapplet-4.0 >= 1.17.0) were not met Messy, can't figure where to get libmatepanelapplet-4.0 from, not available for install in (my) Ubuntu 18.04.1 box.

So that meant going "blind" with valgrind. First run without log to file - my bad - for about two hours. Got positive integer in "definitely lost" section. Second run with logging valgrind --tool=memcheck --leak-check=full --log-file=%p_battstat_valgrind.log --time-stamp=yes /usr/lib/mate-applets/battstat-applet

gives the messages attached (pasted text but it formats horribly). Hope it helps, even though the function calls are unknown... 8899_battstat_valgrind.log

ymollard commented 5 years ago

bionic only has package libmatepanelapplet-4.1, in version 1.20, so this is strange it wants 4-0.

When searching for the sources, I can only find 4-0 (with the actual 1.20 version included in bionic). Maybe compiling and installing this package would help?

Could you post here your compiling procedure from git clone (including the branch you used) to the actual compiling command before valgrinding?

Testing an old distrib might also prevent having a headache with this 4-1 thing. Although even trusty has 4-1 version 1.12, so I don't understand what 4-0 and 4-1 mean here.

I guess testing should been done on a spare laptop, that would prevent breaking the OS you use every day + it might also be useful to let it running a couple of days instead of only 2hrs.

AlexTalker commented 4 years ago

I can confirm that this is still the case for Manjaro and Mate 1.22.2. It consumed 4.2% from 8 GiB RAM in matter of 15 days(or less, unless I killed it during the two weeks - can't recall precisely). Total run time is 11:17.52 for the battstat-applet process. Can I help you out with debugging it?

AlexTalker commented 4 years ago

The laptop is on power all the time, might that be the case? Each day I put it to sleep(by the end of the work).

AlexTalker commented 4 years ago

@ymollard @jackBzzz So, do you need any help with it?

ymollard commented 4 years ago

@AlexTalker I guess the next step is to kill the default battstat-applet, test it with valgrind to make sure you'll be able to retrieve valgrind's verbose logs and then run /usr/lib/mate-applets/battstat-applet in valgrind on the long term ...by provoking it to fail if you know how to.

I'm now using Mate 1.22.2 on Ubuntu 19.10, there's no need of battstat-applet because mate-indicator-applet-complete has battery information.

AlexTalker commented 4 years ago

@ymollard could you sent me a complete command for valgrind? In just couple of days it went from 0.3% to 1.2%. Guess that's a nice grown up.

AlexTalker commented 4 years ago

@ymollard I have Mate 1.22.2, dunno if mate-indicator-applet-complete is installed.... Anyway, I DISABLED the icon and that's what annoying me.

ymollard commented 4 years ago

@AlexTalker yes any mem increase would give clues. Check the right valgrind options for memory leaks there https://www.cprogramming.com/debugging/valgrind.html See if /usr/lib/mate-indicator-applet/mate-indicator-applet-complete does the job.

AlexTalker commented 4 years ago

And so I ran:

$ valgrind --tool=memcheck --leak-check=yes /usr/lib/mate-applets/battstat-applet 
==16977== Memcheck, a memory error detector
==16977== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16977== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==16977== Command: /usr/lib/mate-applets/battstat-applet
==16977== 
^C==16977== 
==16977== Process terminating with default action of signal 2 (SIGINT)
==16977==    at 0x56189EF: poll (in /usr/lib/libc-2.30.so)
==16977==    by 0x546B11F: ??? (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x546C0C2: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x4B1664E: gtk_main (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x488973E: ??? (in /usr/lib/libmate-panel-applet-4.so.1.0.1)
==16977==    by 0x10C14E: ??? (in /usr/lib/mate-applets/battstat-applet)
==16977==    by 0x554B152: (below main) (in /usr/lib/libc-2.30.so)
==16977== 
==16977== HEAP SUMMARY:
==16977==     in use at exit: 1,652,295 bytes in 18,053 blocks
==16977==   total heap usage: 277,686 allocs, 259,633 frees, 19,038,566 bytes allocated
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,341 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D8F: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1935: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,342 of 6,488
==16977==    at 0x48386AF: malloc (vg_replace_malloc.c:308)
==16977==    by 0x483ADE7: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D00: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1935: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,343 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D8F: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1994: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,344 of 6,488
==16977==    at 0x48386AF: malloc (vg_replace_malloc.c:308)
==16977==    by 0x483ADE7: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D00: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1994: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,345 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D8F: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1A5C: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,346 of 6,488
==16977==    at 0x48386AF: malloc (vg_replace_malloc.c:308)
==16977==    by 0x483ADE7: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D00: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1A5C: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,347 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D8F: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B2AF0: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,348 of 6,488
==16977==    at 0x48386AF: malloc (vg_replace_malloc.c:308)
==16977==    by 0x483ADE7: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53B4D00: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB57: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B2AF0: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,349 of 6,488
==16977==    at 0x483877F: malloc (vg_replace_malloc.c:309)
==16977==    by 0x54638D9: g_malloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x5444893: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53E0BA6: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53E0CC5: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B4E3B: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B512A: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD4B8: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD909: g_type_add_interface_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4C2AB2A: ??? (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x4C2AB94: gtk_button_get_type (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x4A241EB: ??? (in /usr/lib/libgtk-3.so.0.2406.7)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,350 of 6,488
==16977==    at 0x483877F: malloc (vg_replace_malloc.c:309)
==16977==    by 0x54638D9: g_malloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x5444893: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53E0BA6: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53E0CC5: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B4E3B: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B521E: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD4B8: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD909: g_type_add_interface_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4B4AF17: ??? (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x4B4AFE4: gtk_icon_view_get_type (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x484C10F: gtk_module_init (in /usr/lib/gtk-3.0/modules/libcanberra-gtk3-module.so)
==16977== 
==16977== 16 bytes in 1 blocks are possibly lost in loss record 1,351 of 6,488
==16977==    at 0x483877F: malloc (vg_replace_malloc.c:309)
==16977==    by 0x54638D9: g_malloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x5444893: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53E0BA6: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53E0CC5: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B4E3B: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B512A: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD4B8: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD909: g_type_add_interface_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4B4AF7A: ??? (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x4B4AFE4: gtk_icon_view_get_type (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x484C10F: gtk_module_init (in /usr/lib/gtk-3.0/modules/libcanberra-gtk3-module.so)
==16977== 
==16977== 24 bytes in 1 blocks are possibly lost in loss record 1,912 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BCFEC: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53D2478: g_param_spec_flags (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x5011C10: ??? (in /usr/lib/libgdk-3.so.0.2406.7)
==16977==    by 0x53BCE71: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DA587: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DAC89: g_object_new (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4FC3D0A: ??? (in /usr/lib/libgdk-3.so.0.2406.7)
==16977==    by 0x4FC3551: ??? (in /usr/lib/libgdk-3.so.0.2406.7)
==16977== 
==16977== 32 bytes in 1 blocks are possibly lost in loss record 3,019 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BCFEC: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53D2578: g_param_spec_enum (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4FEDC08: ??? (in /usr/lib/libgdk-3.so.0.2406.7)
==16977==    by 0x53BCE71: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DA587: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DAC89: g_object_new (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4FAF38C: ??? (in /usr/lib/libgdk-3.so.0.2406.7)
==16977==    by 0x4FB197B: ??? (in /usr/lib/libgdk-3.so.0.2406.7)
==16977== 
==16977== 48 bytes in 3 blocks are possibly lost in loss record 3,768 of 6,488
==16977==    at 0x483877F: malloc (vg_replace_malloc.c:309)
==16977==    by 0x54638D9: g_malloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x5444893: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53E0BA6: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53E0CC5: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B4E3B: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B521E: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD4B8: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD909: g_type_add_interface_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4C2AAF7: ??? (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x4C2AB94: gtk_button_get_type (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x4A241EB: ??? (in /usr/lib/libgtk-3.so.0.2406.7)
==16977== 
==16977== 64 bytes in 1 blocks are possibly lost in loss record 4,262 of 6,488
==16977==    at 0x483AD7B: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF175: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BAC5C: g_type_register_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DDAB8: g_flags_register_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4C5F89C: gtk_state_flags_get_type (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x49D9A3F: ??? (in /usr/lib/libgtk-3.so.0.2406.7)
==16977==    by 0x53BCE71: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x484A1B8: ??? (in /usr/lib/gtk-3.0/modules/libcanberra-gtk3-module.so)
==16977== 
==16977== 80 bytes in 1 blocks are possibly lost in loss record 4,661 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BCFEC: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD128: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53D1C5C: g_param_spec_internal (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53D1FB2: g_param_spec_object (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x500AD53: ??? (in /usr/lib/libgdk-3.so.0.2406.7)
==16977==    by 0x53BCE71: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DABD8: g_object_new_with_properties (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DACB1: g_object_new (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x500A6D6: gdk_display_manager_get (in /usr/lib/libgdk-3.so.0.2406.7)
==16977== 
==16977== 96 bytes in 1 blocks are possibly lost in loss record 5,668 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF200: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53C0F3A: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B11E5: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 96 bytes in 1 blocks are possibly lost in loss record 5,669 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF200: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53C0F3A: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB49: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1935: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 96 bytes in 1 blocks are possibly lost in loss record 5,670 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF200: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53C0F3A: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB49: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1994: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 96 bytes in 1 blocks are possibly lost in loss record 5,671 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF200: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53C0F3A: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB49: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1A5C: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 96 bytes in 1 blocks are possibly lost in loss record 5,672 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF200: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53C0F3A: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBB49: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B2AF0: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 132 bytes in 1 blocks are possibly lost in loss record 5,953 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53C005D: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBBD9: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1935: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 132 bytes in 1 blocks are possibly lost in loss record 5,954 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53C005D: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBBD9: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1994: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 148 bytes in 1 blocks are possibly lost in loss record 5,989 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BFE6B: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBBD9: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1A5C: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 148 bytes in 1 blocks are possibly lost in loss record 5,990 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x54637C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BFE6B: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BBBD9: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B2AF0: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 184 bytes in 1 blocks are possibly lost in loss record 6,055 of 6,488
==16977==    at 0x483AD7B: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF175: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BAC5C: g_type_register_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53D06A2: g_param_type_register_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B3977: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53B1B4C: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x4010729: call_init.part.0 (in /usr/lib/ld-2.30.so)
==16977==    by 0x4010830: _dl_init (in /usr/lib/ld-2.30.so)
==16977==    by 0x4002139: ??? (in /usr/lib/ld-2.30.so)
==16977== 
==16977== 352 bytes in 1 blocks are possibly lost in loss record 6,187 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x4012A51: allocate_dtv (in /usr/lib/ld-2.30.so)
==16977==    by 0x40133C1: _dl_allocate_tls (in /usr/lib/ld-2.30.so)
==16977==    by 0x5DDF1BE: pthread_create@@GLIBC_2.2.5 (in /usr/lib/libpthread-2.30.so)
==16977==    by 0x544AC1A: ??? (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x544AE48: g_thread_new (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x546A2C0: ??? (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x5282F42: ??? (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x5282FF4: g_task_get_type (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x522439A: ??? (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x5233FB2: g_bus_get_sync (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x6D8A9DD: ??? (in /usr/lib/gio/modules/libgvfsdbus.so)
==16977== 
==16977== 352 bytes in 1 blocks are possibly lost in loss record 6,188 of 6,488
==16977==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
==16977==    by 0x4012A51: allocate_dtv (in /usr/lib/ld-2.30.so)
==16977==    by 0x40133C1: _dl_allocate_tls (in /usr/lib/ld-2.30.so)
==16977==    by 0x5DDF1BE: pthread_create@@GLIBC_2.2.5 (in /usr/lib/libpthread-2.30.so)
==16977==    by 0x544AC1A: ??? (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x544AE48: g_thread_new (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x5239288: ??? (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x5234014: g_bus_get_sync (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x6D8A9DD: ??? (in /usr/lib/gio/modules/libgvfsdbus.so)
==16977==    by 0x53BD33F: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53D9765: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DABB4: g_object_new_with_properties (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977== 
==16977== 360 bytes in 1 blocks are possibly lost in loss record 6,195 of 6,488
==16977==    at 0x483AD7B: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF175: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BAC5C: g_type_register_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53DDBA8: g_enum_register_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x508690C: atk_role_get_type (in /usr/lib/libatk-1.0.so.0.23410.1)
==16977==    by 0x5083646: ??? (in /usr/lib/libatk-1.0.so.0.23410.1)
==16977==    by 0x53BCE71: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BD00D: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977== 
==16977== 560 bytes in 1 blocks are possibly lost in loss record 6,269 of 6,488
==16977==    at 0x483AD7B: realloc (vg_replace_malloc.c:836)
==16977==    by 0x5463718: g_realloc (in /usr/lib/libglib-2.0.so.0.6200.4)
==16977==    by 0x53BF175: ??? (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BAC5C: g_type_register_static (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x53BB6E5: g_type_register_static_simple (in /usr/lib/libgobject-2.0.so.0.6200.4)
==16977==    by 0x529F1BF: ??? (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x529F264: g_simple_async_result_get_type (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x52ECB32: g_async_result_legacy_propagate_error (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x52ECE2C: g_async_initable_init_finish (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x5232F3D: ??? (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x5280DC3: ??? (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977==    by 0x5280DF8: ??? (in /usr/lib/libgio-2.0.so.0.6200.4)
==16977== 
==16977== LEAK SUMMARY:
==16977==    definitely lost: 0 bytes in 0 blocks
==16977==    indirectly lost: 0 bytes in 0 blocks
==16977==      possibly lost: 3,272 bytes in 32 blocks
==16977==    still reachable: 1,566,439 bytes in 17,347 blocks
==16977==                       of which reachable via heuristic:
==16977==                         length64           : 5,000 bytes in 83 blocks
==16977==                         newarray           : 2,064 bytes in 49 blocks
==16977==         suppressed: 0 bytes in 0 blocks
==16977== Reachable blocks (those to which a pointer was found) are not shown.
==16977== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==16977== 
==16977== For lists of detected and suppressed errors, rerun with: -s
==16977== ERROR SUMMARY: 30 errors from 30 contexts (suppressed: 0 from 0)

And overall, seems that it used less memory than initally(or Linux doesn't count swap?). I'm not sure what triggered the leak before.

alwilson commented 4 years ago

I'm using Mate 1.24.0 on Arch Linux and battstat-applet leaks fairly quickly for me. In a single day it leaked on the order of 4+ GB. I've noticed adding more instances of the applet to the panel helps it leak faster as well, since it appears there's only ever one underlying process. I ran strace for mmap and brk calls and found that no mmap calls were made, but brk calls were made consistently as it ran.

I used gdb to get a backtrace and found the source of the brk syscalls. battstat-upower.c:158 calls the libupower-glib which eventually calls brk after :

GPtrArray *devices = up_client_get_devices( upc );

gdb backtrace snippet:

(gdb) catch syscall brk
Catchpoint 1 (syscall 'brk' [12])
(gdb) c
Continuing.

Thread 1 "battstat-applet" hit Catchpoint 1 (call to syscall brk), 0x00007f3af09e81cb in brk () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007f3af09e81cb in brk () at /usr/lib/libc.so.6
#1  0x00007f3af09e82b1 in sbrk () at /usr/lib/libc.so.6
#2  0x00007f3af097e97d in __default_morecore () at /usr/lib/libc.so.6
#3  0x00007f3af097ab82 in sysmalloc () at /usr/lib/libc.so.6
#4  0x00007f3af097bd22 in _int_malloc () at /usr/lib/libc.so.6
#5  0x00007f3af097c6cf in _int_realloc () at /usr/lib/libc.so.6
#6  0x00007f3af097d986 in realloc () at /usr/lib/libc.so.6
#7  0x00007f3af0c62899 in g_realloc () at /usr/lib/libglib-2.0.so.0
#8  0x00007f3af0e0d09d in  () at /usr/lib/libgio-2.0.so.0
#9  0x00007f3af0e0f7a8 in  () at /usr/lib/libgio-2.0.so.0
#10 0x00007f3af0e0f0d4 in  () at /usr/lib/libgio-2.0.so.0
#11 0x00007f3af0e0f633 in  () at /usr/lib/libgio-2.0.so.0
#12 0x00007f3af0e0f208 in  () at /usr/lib/libgio-2.0.so.0
#13 0x00007f3af0e15999 in g_dbus_message_to_blob () at /usr/lib/libgio-2.0.so.0
#14 0x00007f3af0e19fd4 in  () at /usr/lib/libgio-2.0.so.0
#15 0x00007f3af0e1bc60 in  () at /usr/lib/libgio-2.0.so.0
#16 0x00007f3af0e1be0e in g_dbus_connection_send_message_with_reply () at /usr/lib/libgio-2.0.so.0
#17 0x00007f3af0e1c027 in g_dbus_connection_send_message_with_reply_sync () at /usr/lib/libgio-2.0.so.0
#18 0x00007f3af0e1c454 in  () at /usr/lib/libgio-2.0.so.0
#19 0x00007f3af0e0aea2 in  () at /usr/lib/libgio-2.0.so.0
#20 0x00007f3af0e0b034 in g_dbus_proxy_call_sync () at /usr/lib/libgio-2.0.so.0
#21 0x00007f3af0d90b2b in up_exported_daemon_call_enumerate_devices_sync () at /usr/lib/libupower-glib.so.3
#22 0x00007f3af0d8ae7f in up_client_get_devices2 () at /usr/lib/libupower-glib.so.3
#23 0x00007f3af0d8af98 in up_client_get_devices () at /usr/lib/libupower-glib.so.3
#24 0x0000559aecb239b5 in battstat_upower_get_battery_info (status=0x7fffd49a6c60) at battstat-upower.c:158
#25 0x0000559aecb22ac5 in power_management_getinfo (status=0x7fffd49a6c60) at power-management.c:400
#26 0x0000559aecb20f7e in check_for_updates (data=0x559aedf53e80) at battstat_applet.c:618
#27 0x00007f3af0c67be4 in  () at /usr/lib/libglib-2.0.so.0
#28 0x00007f3af0c683ef in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#29 0x00007f3af0c6a2d1 in  () at /usr/lib/libglib-2.0.so.0
#30 0x00007f3af0c6b263 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#31 0x00007f3af15e194f in gtk_main () at /usr/lib/libgtk-3.so.0
#32 0x00007f3af1a417cf in  () at /usr/lib/libmate-panel-applet-4.so.1
#33 0x0000559aecb1fd72 in main (argc=<optimized out>, argv=<optimized out>) at battstat_applet.c:1189

I pulled master (71d007c4765e) and played around with battstat-upower.c until I realized that it only needs to call that upower function once. I don't know if that's the correct long-term fix, but it stops the memory leak for me. There are some upower version checks going on that might not make this work everywhere. It would be interesting to see if this works for anyone else. I tested it by replacing my system binary, killing all battstat applets and processes, and creating 5+ new battstat instances. With these changes it reaches 27 MB quickly and appears to stay there. Before it would gradually grow by a MB every couple of seconds (with multiple applets on the panel calling the update function). battstat-upower-call-once-up_client_get_devices.diff.txt (You can't upload diff files to github?)

I also installed mate-power-manager and it comes with a nice battery indicator, although it lacks the options to display the charge percentage or time remaining. I haven't seen this /usr/lib/mate-indicator-applet/mate-indicator-applet-complete applet yet, although it might be hidden under a different mate package in arch.

Notes:

I don't have a right click menu on the applets I built myself, but the hover tooltip works.
After pulling master and installing the mate-common package I was able to start building (./autogen.sh), but a language file was missing, ms.po. Is that just something on my end? I created a fake version by copying en_GB.po, but master (71d007c4765e) doesn't appear to build.

Edit:

Duplicate sentence/note removed

AlexTalker commented 4 years ago

@alwilson nice work, could you make a PR then? And, I'd just rebuild the package from which the file came from in debug mode, then all the functionality should work.

alwilson commented 4 years ago

@AlexTalker That's a good point on just rebuilding the actual package. Yeah, I can make a PR.

AlexTalker commented 4 years ago

@alwilson Anyway, will put preview here:

diff --git a/battstat/battstat-upower.c b/battstat/battstat-upower.c
index 67779f8c..a1e545df 100644
--- a/battstat/battstat-upower.c
+++ b/battstat/battstat-upower.c
@@ -43,6 +43,8 @@ static void (*status_updated_callback) (void);
  */
 static gboolean status_update_scheduled;

+static GPtrArray *devices;
+
 static gboolean
 update_status_idle (gpointer junk)
 {
@@ -83,9 +85,6 @@ battstat_upower_initialise (void (*callback) (void))
   int i, num;

   status_updated_callback = callback;
-#if UP_CHECK_VERSION (0, 99, 0)
-  GPtrArray *devices;
-#endif

   if( upc != NULL )
     return g_strdup( "Already initialised!" );
@@ -101,7 +100,6 @@ battstat_upower_initialise (void (*callback) (void))
   if (!devices) {
     goto error_shutdownclient;
   }
-  g_ptr_array_unref(devices);
 #else
   if (! up_client_enumerate_devices_sync( upc, cancellable, &gerror ) ) {
     sprintf(error_str, "Unable to enumerate upower devices: %s\n", gerror->message);
@@ -132,7 +130,7 @@ battstat_upower_cleanup( void )
 {
   if( upc == NULL )
     return;
-  
+
   g_object_unref( upc );
   upc = NULL;
 }
@@ -154,9 +152,6 @@ battstat_upower_cleanup( void )
 void
 battstat_upower_get_battery_info( BatteryStatus *status )
 {
-
-  GPtrArray *devices = up_client_get_devices( upc );
-
   /* The calculation to get overall percentage power remaining is as follows:
    *
    *    Sum( Current charges ) / Sum( Full Capacities )
@@ -211,7 +206,7 @@ battstat_upower_get_battery_info( BatteryStatus *status )
     int type, state;
     double current_charge, full_capacity, rate;
     gint64 time_to_full, time_to_empty;
-    
+
     g_object_get( upd,
       "kind", &type,
       "state", &state,
@@ -259,7 +254,6 @@ battstat_upower_get_battery_info( BatteryStatus *status )
     status->on_ac_power = TRUE;
     status->charging = FALSE;

-    g_ptr_array_unref( devices );
     return;
   }

@@ -279,7 +273,7 @@ battstat_upower_get_battery_info( BatteryStatus *status )
      * (ie: the PMU or APM subsystem).
      *
      * upower gives remaining time in seconds with a 0 to mean that the
-     * remaining time is unknown.  Battstat uses minutes and -1 for 
+     * remaining time is unknown.  Battstat uses minutes and -1 for
      * unknown time remaining.
      */

@@ -326,8 +320,6 @@ battstat_upower_get_battery_info( BatteryStatus *status )
   /* These are simple and well-explained above. */
   status->charging = charging;
   status->on_ac_power = on_ac_power;
-  
-  g_ptr_array_unref( devices );
 }

 void

AlexTalker commented 4 years ago

@alwilson I think you need to add unref into battstat_upower_cleanup to keep initialization/destruction intact.

And remove from the patch unrelated changes.

alwilson commented 4 years ago

@AlexTalker Ah, yeah, my vim auto whitespace cleanup is noisy. Feedback on the UP_CHECK_VERSION ifdefs?

mate-desktop / mate-applets

Memory leak of battstat-applet #345