With the patch provided to remove the extra up_client_new() calls, I still see these 3 leaks from within up_client_get_devices().
Neither g_ptr_array_free() or g_ptr_array_unref() are cleaning them up. I'm assuming a more comprehensive fix would be to remove up_client_get_devices() from upower_read() since it seems to be internally leaking in libupower-glib and save the data from the call in upower_supported() for each polling cycle instead of discarding it each time. ==17098== ==17098== 5,968 bytes in 746 blocks are possibly lost in loss record 1,557 of 1,606 ==17098== at 0x4238A0E: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x421A9D5: g_object_new_internal (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x421C4A5: g_object_newv (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x421CACC: g_object_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x41EDB06: up_device_new (in /usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0) ==17098== by 0x41E8FC6: up_client_get_devices (in /usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0) ==17098== by 0x804BE5A: upower_read (upower.c:89) ==17098== by 0x804A996: alarmhandler (wmbattery.c:711) ==17098== by 0x43BD3F7: ??? (in /lib/i386-linux-gnu/i686/cmov/libc-2.19.so) ==17098== ==17098== 14,920 bytes in 746 blocks are possibly lost in loss record 1,566 of 1,606 ==17098== at 0x42389C2: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x421A9D5: g_object_new_internal (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x421C4A5: g_object_newv (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x421CACC: g_object_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x41EDB06: up_device_new (in /usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0) ==17098== by 0x41E8FC6: up_client_get_devices (in /usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0) ==17098== by 0x804BE5A: upower_read (upower.c:89) ==17098== by 0x804A996: alarmhandler (wmbattery.c:711) ==17098== by 0x43BD3F7: ??? (in /lib/i386-linux-gnu/i686/cmov/libc-2.19.so) ==17098== ==17098== 26,856 bytes in 746 blocks are possibly lost in loss record 1,584 of 1,606 ==17098== at 0x402C0D5: calloc (vg_replace_malloc.c:623) ==17098== by 0x42B3745: g_malloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1) ==17098== by 0x42148C4: g_closure_new_simple (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x4215C28: g_cclosure_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x422DF1C: g_signal_connect_data (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1) ==17098== by 0x41ECAB2: up_device_set_object_path_sync (in /usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0) ==17098== by 0x41E8FD3: up_client_get_devices (in /usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0) ==17098== by 0x804BE5A: upower_read (upower.c:89) ==17098== by 0x804A996: alarmhandler (wmbattery.c:711) ==17098== by 0x43BD3F7: ??? (in /lib/i386-linux-gnu/i686/cmov/libc-2.19.so) ==17098== -- David Johnson Principal Engineer
