Description of problem: I recently updated to F21 from F20. After a couple of days of usage, my system became really sluggish. Checking 'top' showed a lot of swap space was in use, and upower was the highest cpu consumer at that instant with a lot of RAM allocated to it -- 70% of my 8G RAM. Here's the output from 'top' at one such instance: 9959 root 20 0 7235484 5.336g 68 D 11.6 69.5 7:27.96 upowerd Looks like a memory leak somewhere. One note: I had plugged in the power connector and the battery was charging. While in this state, I suspended the laptop. While resuming, I had disconnected the power; but the icon in gnome-shell showed as still charging, but my battery was near 0% as I wasn't warned about it. Maybe this is related to the mem leak as well. Version-Release number of selected component (if applicable): upower-0.99.1-2.fc21.x86_64
I've seen this too. Here's gdb: (gdb) bt #0 0x00007f130170c6c6 in signal_emit_unlocked_R (handler=0x7f135e377010) at gsignal.c:587 #1 0x00007f130170c6c6 in signal_emit_unlocked_R (node=<optimized out>, detail=122, instance=0x7f13047a22b0, emission_return=0x0, instance_and_params=0x7fffdba40070) at gsignal.c:3570 #2 0x00007f1301715191 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at gsignal.c:3337 #3 0x00007f13017153bf in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3367 #4 0x00007f13016ff465 in g_object_dispatch_properties_changed (object=0x7f13047a22b0 [UpDeviceSupply], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056 #5 0x00007f13016fecce in g_object_notify_queue_thaw (object=0x7f13047a22b0 [UpDeviceSupply], nqueue=<optimized out>) at gobject.c:289 #6 0x00007f130170275d in g_object_set_valist (object=0x7f13047a22b0 [UpDeviceSupply], first_property_name=<optimized out>, var_args=0x7fffdba404d0) at gobject.c:2115 #7 0x00007f1301702f9c in g_object_set (_object=_object@entry=0x7f13047a22b0, first_property_name=first_property_name@entry=0x7f1302aa62cd "energy") at gobject.c:2268 #8 0x00007f1302a9f8b8 in up_device_supply_refresh (out_state=0x7fffdba40688, supply=0x7f13047a22b0 [UpDeviceSupply]) at up-device-supply.c:793 #9 0x00007f1302a9f8b8 in up_device_supply_refresh (device=<optimized out>) at up-device-supply.c:1103 #10 0x00007f1302a9874c in up_device_refresh_internal (device=device@entry=0x7f13047a22b0 [UpDeviceSupply]) at up-device.c:889 #11 0x00007f1302a96235 in up_daemon_device_changed_cb (daemon=<optimized out>) at up-daemon.c:408 #12 0x00007f1302a96235 in up_daemon_device_changed_cb (device=<optimized out>, pspec=<optimized out>, daemon=<optimized out>) at up-daemon.c:851 g_signal_emit never finished, and looking there was fun: (gdb) print *handler $2 = {sequential_number = 11225688, next = 0x7f13613b24d0, prev = 0x7f13613b2470, detail = 123, ref_count = 2, block_count = 0, after = 0, has_invalid_closure_notify = 0, closure = 0x7f13613b2f30} (gdb) print *handler->next $4 = {sequential_number = 11225689, next = 0x7f13613b2500, prev = 0x7f13613b24a0, detail = 123, ref_count = 1, block_count = 0, after = 0, has_invalid_closure_notify = 0, closure = 0x7f13613b2f80} (gdb) print *handler->next->next $5 = {sequential_number = 11225690, next = 0x7f13613b2530, prev = 0x7f13613b24d0, detail = 123, ref_count = 1, block_count = 0, after = 0, has_invalid_closure_notify = 0, This continued pretty much ad nauseum. Unfortunately all the useful debug information I could see (e.g. which signal it actually was!) was elided, other than this: (gdb) print *handler->closure $16 = {ref_count = 1, meta_marshal_nouse = 0, n_guards = 0, n_fnotifiers = 0, n_inotifiers = 0, in_inotify = 0, floating = 0, derivative_flag = 0, in_marshal = 0, is_invalid = 0, marshal = 0x7f13016fda40 <g_cclosure_marshal_VOID__STRINGv+272>, data = 0x0, notifiers = 0x0} But I'd guess that it's perhaps a signal handler ultimately adding a handler to the same signal, triggering an infinite loop that also increases memory consumption?
*** This bug has been marked as a duplicate of bug 1148312 ***