Bug 1163747

Summary:	upower uses 5.3G of RAM (and growing)
Product:	[Fedora] Fedora	Reporter:	Amit Shah <amit.shah>
Component:	upower	Assignee:	Richard Hughes <rhughes>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	21	CC:	amit.shah, daniel, rhughes
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-01 18:44:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Amit Shah 2014-11-13 12:14:04 UTC

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

Comment 1 Daniel Stone 2014-11-19 03:44:55 UTC

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?

Comment 2 Bill Nottingham 2014-12-01 18:44:04 UTC


*** This bug has been marked as a duplicate of bug 1148312 ***