Bug 1128390 - [abrt] upower: g_variant_unref(): upower killed by SIGSEGV
Summary: [abrt] upower: g_variant_unref(): upower killed by SIGSEGV
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: upower
Version: 21
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:91cbba12c9b2f50465e8d38c62c...
: 1182349 1190677 1196643 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-10 00:52 UTC by D. Charles Pyle
Modified: 2015-03-27 00:05 UTC (History)
10 users (show)

Fixed In Version: upower-0.99.2-4.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-26 22:10:01 UTC


Attachments (Terms of Use)
File: backtrace (21.53 KB, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: cgroup (190 bytes, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: core_backtrace (11.37 KB, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: dso_list (1.43 KB, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: environ (3.96 KB, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: exploitable (82 bytes, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: limits (1.29 KB, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: maps (7.37 KB, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: open_fds (365 bytes, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: proc_pid_status (969 bytes, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
File: var_log_messages (949 bytes, text/plain)
2014-08-10 00:52 UTC, D. Charles Pyle
no flags Details
fix for upower (839 bytes, patch)
2015-03-03 14:11 UTC, Wolfgang Ulbrich
no flags Details | Diff

Description D. Charles Pyle 2014-08-10 00:52:25 UTC
Description of problem:
System is acting like it is running on battery all the time.  It isn't running on battery at all.  mate-power-manager doesn't display properpower status.  It relies on upower for its information, which it isn't getting.  There is no information or files in /sys/class/power_supply like there should be.  Directory is empty but should contain an item named AC.  In order for my system to see that there is AC I have to force it using sudo tlp ac but should not need to do this.  Tried running upower -d and, most recently, upower --dump, which both cause upower to segfault every time.  I have tried everything I can think of to fix this including removing and reinstalling the packages for both upower and mate-power-manager.  Other than that I am not sure why it is that upower isn't working right.  This has been going on for weeks.

Version-Release number of selected component:
upower-0.99.0-6.fc21

Additional info:
reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        upower --monitor-detail
crash_function: g_variant_unref
executable:     /usr/bin/upower
kernel:         3.16.0-1.fc21.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 g_variant_unref at gvariant-core.c:627
 #1 up_device_get_history_sync at up-device.c:475
 #2 up_device_to_text_history at up-device.c:185
 #3 up_device_to_text at up-device.c:366
 #4 up_tool_device_changed_cb at up-tool.c:94
 #10 g_object_notify_by_spec_internal at gobject.c:1149
 #11 g_object_notify at gobject.c:1197
 #17 g_object_notify_by_spec_internal at gobject.c:1149
 #18 g_object_notify at gobject.c:1197
 #19 up_device_glue_proxy_g_properties_changed at up-device-glue.c:2686

Comment 1 D. Charles Pyle 2014-08-10 00:52:27 UTC
Created attachment 925431 [details]
File: backtrace

Comment 2 D. Charles Pyle 2014-08-10 00:52:28 UTC
Created attachment 925432 [details]
File: cgroup

Comment 3 D. Charles Pyle 2014-08-10 00:52:29 UTC
Created attachment 925433 [details]
File: core_backtrace

Comment 4 D. Charles Pyle 2014-08-10 00:52:29 UTC
Created attachment 925434 [details]
File: dso_list

Comment 5 D. Charles Pyle 2014-08-10 00:52:30 UTC
Created attachment 925435 [details]
File: environ

Comment 6 D. Charles Pyle 2014-08-10 00:52:31 UTC
Created attachment 925436 [details]
File: exploitable

Comment 7 D. Charles Pyle 2014-08-10 00:52:31 UTC
Created attachment 925437 [details]
File: limits

Comment 8 D. Charles Pyle 2014-08-10 00:52:32 UTC
Created attachment 925438 [details]
File: maps

Comment 9 D. Charles Pyle 2014-08-10 00:52:33 UTC
Created attachment 925439 [details]
File: open_fds

Comment 10 D. Charles Pyle 2014-08-10 00:52:34 UTC
Created attachment 925440 [details]
File: proc_pid_status

Comment 11 D. Charles Pyle 2014-08-10 00:52:34 UTC
Created attachment 925441 [details]
File: var_log_messages

Comment 12 D. Charles Pyle 2014-08-12 17:43:59 UTC
Here is what I get when I run upower --dump

Device: /org/freedesktop/UPower/devices/ups_hiddev0
Segmentation fault (core dumped)

Comment 13 leigh scott 2014-12-29 21:23:00 UTC
Another user experienced a similar problem:

Ran 'upower -d' in terminal

reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        upower -d
crash_function: g_variant_unref
executable:     /usr/bin/upower
kernel:         3.18.1-2.fc21.1.x86_64
package:        upower-0.99.1-3.fc21
reason:         upower killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Comment 14 leigh scott 2015-01-03 10:53:38 UTC
Marking Severity as urgent as F21 is unusable here till this issue is fixed.

Every AC outage and upower shutsdown my PC straight away even though my UPS has a full charge.
upower fails to see the full charge after AC outage.
In F20 my PC will run 20 minutes till the UPS is empty then shutdown.

Comment 15 Richard Hughes 2015-01-05 11:00:32 UTC
Can you try with https://admin.fedoraproject.org/updates/upower-0.99.2-1.fc21 please.

Comment 16 leigh scott 2015-01-06 10:46:45 UTC
(In reply to Richard Hughes from comment #15)
> Can you try with
> https://admin.fedoraproject.org/updates/upower-0.99.2-1.fc21 please.

No change


(gdb) run -d
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/upower -d
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffef671700 (LWP 18972)]
Device: /org/freedesktop/UPower/devices/ups_hiddev0

Program received signal SIGSEGV, Segmentation fault.
g_variant_unref (value=0x7ffff7bd0800) at gvariant-core.c:627
627	  if (g_atomic_int_dec_and_test (&value->ref_count))
(gdb) bt
#0  0x00007ffff76b05f4 in g_variant_unref (value=0x7ffff7bd0800)
    at gvariant-core.c:627
#1  0x00007ffff7bc49d6 in up_device_get_history_sync (device=device@entry=0x7fffe8003c70 [UpDevice], type=type@entry=0x7ffff7bcfbf3 "charge", timespec=timespec@entry=120, resolution=resolution@entry=10, cancellable=cancellable@entry=0x0, error=error@entry=0x0) at up-device.c:484
#2  0x00007ffff7bc4b5a in up_device_to_text_history (device=device@entry=0x7fffe8003c70 [UpDevice], string=string@entry=0x631340, type=type@entry=0x7ffff7bcfbf3 "charge") at up-device.c:194
#3  0x00007ffff7bc5302 in up_device_to_text (device=device@entry=0x7fffe8003c70 [UpDevice]) at up-device.c:375
#4  0x0000000000401626 in main (argc=1, argv=0x7fffffffe058) at up-tool.c:321
(gdb)

Comment 17 leigh scott 2015-01-06 10:57:40 UTC
(gdb) run --monitor-detail
Starting program: /usr/bin/upower --monitor-detail
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffef671700 (LWP 19275)]
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[10:56:17.169]	device changed:     /org/freedesktop/UPower/devices/ups_hiddev0

Program received signal SIGSEGV, Segmentation fault.
g_variant_unref (value=0x7ffff7bd0800) at gvariant-core.c:627
627	  if (g_atomic_int_dec_and_test (&value->ref_count))
(gdb) bt
#0  0x00007ffff76b05f4 in g_variant_unref (value=0x7ffff7bd0800) at gvariant-core.c:627
#1  0x00007ffff7bc49d6 in up_device_get_history_sync (device=device@entry=0x613f70 [UpDevice], type=type@entry=0x7ffff7bcfbf3 "charge", timespec=timespec@entry=120, resolution=resolution@entry=10, cancellable=cancellable@entry=0x0, error=error@entry=0x0) at up-device.c:484
#2  0x00007ffff7bc4b5a in up_device_to_text_history (device=device@entry=0x613f70 [UpDevice], string=string@entry=0x631760, type=type@entry=0x7ffff7bcfbf3 "charge") at up-device.c:194
#3  0x00007ffff7bc5302 in up_device_to_text (device=device@entry=0x613f70 [UpDevice]) at up-device.c:375
#4  0x0000000000401c7f in up_tool_device_changed_cb (device=0x613f70 [UpDevice], pspec=<optimized out>, user_data=<optimized out>) at up-tool.c:94
#8  0x00007ffff798f3af in <emit signal notify:state on instance 0x613f70 [UpDevice]> (instance=instance@entry=0x613f70, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3365
    #5  0x00007ffff7974d35 in g_closure_invoke (closure=0x628480, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffcc90, invocation_hint=invocation_hint@entry=0x7fffffffcc30) at gclosure.c:768
    #6  0x00007ffff7986a42 in signal_emit_unlocked_R (node=node@entry=0x6109e0, detail=detail@entry=208, instance=instance@entry=0x613f70, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcc90) at gsignal.c:3553
    #7  0x00007ffff798f181 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffce20) at gsignal.c:3309
#9  0x00007ffff7979475 in g_object_dispatch_properties_changed (object=0x613f70 [UpDevice], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056
#10 0x00007ffff797b8d1 in g_object_notify (pspec=<optimized out>, object=0x613f70 [UpDevice]) at gobject.c:1149
#11 0x00007ffff797b8d1 in g_object_notify (object=0x613f70 [UpDevice], property_name=<optimized out>) at gobject.c:1197
#15 0x00007ffff798f3af in <emit signal notify:state on instance 0x618930 [UpDeviceGlueProxy]> (instance=instance@entry=0x618930, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3365
    #12 0x00007ffff7974d35 in g_closure_invoke (closure=0x62a2a0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd120, invocation_hint=invocation_hint@entry=0x7fffffffd0c0) at gclosure.c:768
    #13 0x00007ffff7986a42 in signal_emit_unlocked_R (node=node@entry=0x6109e0, detail=detail@entry=208, instance=instance@entry=0x618930, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd120) at gsignal.c:3553
    #14 0x00007ffff798f181 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd2b0) at gsignal.c:3309
#16 0x00007ffff7979475 in g_object_dispatch_properties_changed (object=0x618930 [UpDeviceGlueProxy], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056
#17 0x00007ffff797b8d1 in g_object_notify (pspec=<optimized out>, object=0x618930 [UpDeviceGlueProxy]) at gobject.c:1149
#18 0x00007ffff797b8d1 in g_object_notify (object=0x618930 [UpDeviceGlueProxy], property_name=property_name@entry=0x7ffff7bd04c0 "state") at gobject.c:1197
#19 0x00007ffff7bcb99c in up_device_glue_proxy_g_properties_changed (_proxy=<optimized out>, changed_properties=<optimized out>, invalidated_properties=0x630df0) at up-device-glue.c:2698
#20 0x00007ffff6ad9d60 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#21 0x00007ffff6ad97d1 in ffi_call (cif=cif@entry=0x7fffffffd640, fn=<optimized out>, rvalue=0x7fffffffd5a0, avalue=avalue@entry=0x7fffffffd540) at ../src/x86/ffi64.c:525
#26 0x00007ffff798f3af in <emit signal ??? on instance 0x618930 [UpDeviceGlueProxy]> (instance=instance@entry=0x618930, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3365
    #22 0x00007ffff7975554 in g_cclosure_marshal_generic (closure=0x6108d0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x7ffff7bcb840 <up_device_glue_proxy_g_properties_changed>) at gclosure.c:1448
    #23 0x00007ffff7974d35 in g_closure_invoke (closure=closure@entry=0x6108d0, return_value=return_value@entry=0x0, n_param_values=3, param_values=param_values@entry=0x7fffffffd870, invocation_hint=invocation_hint@entry=0x7fffffffd810) at gclosure.c:768
    #24 0x00007ffff798693a in signal_emit_unlocked_R (node=node@entry=0x617500, detail=detail@entry=0, instance=instance@entry=0x618930, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd870) at gsignal.c:3591
    #25 0x00007ffff798f181 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffda20) at gsignal.c:3309
#27 0x00007ffff6fcf649 in on_properties_changed (connection=<optimized out>, sender_name=<optimized out>, object_path=<optimized out>, interface_name=<optimized out>, signal_name=<optimized out>, parameters=<optimized out>, user_data=0x629fc0) at gdbusproxy.c:1139
#28 0x00007ffff6fbf114 in emit_signal_instance_in_idle_cb (data=0x7fffe8009470) at gdbusconnection.c:3753
#29 0x00007ffff7675aeb in g_main_context_dispatch (context=0x60fe10) at gmain.c:3111
#30 0x00007ffff7675aeb in g_main_context_dispatch (context=context@entry=0x60fe10) at gmain.c:3710
#31 0x00007ffff7675e88 in g_main_context_iterate (context=0x60fe10, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#32 0x00007ffff76761b2 in g_main_loop_run (loop=0x60fd80) at gmain.c:3975
#33 0x0000000000401806 in main (client=0x613a20 [UpClient]) at up-tool.c:185
#34 0x0000000000401806 in main (argc=1, argv=0x7fffffffe048) at up-tool.c:346
(gdb)

Comment 18 D. Charles Pyle 2015-01-06 13:27:20 UTC
No change in segfaulting behavior.  Both upower -d and upower --dump still result in segmentation faults and core dumps.

Comment 19 Wolfgang Ulbrich 2015-03-03 14:07:59 UTC
*** Bug 1182349 has been marked as a duplicate of this bug. ***

Comment 20 Wolfgang Ulbrich 2015-03-03 14:08:54 UTC
*** Bug 1190677 has been marked as a duplicate of this bug. ***

Comment 21 Wolfgang Ulbrich 2015-03-03 14:11:24 UTC
Created attachment 997554 [details]
fix for upower

Comment 22 Wolfgang Ulbrich 2015-03-03 14:13:07 UTC
This fixes all the issues with using gnome-power-statistics and similar packages.

Comment 23 Wolfgang Ulbrich 2015-03-03 14:28:56 UTC
.....and it fixes 'upower --monitor-detail'

Comment 24 Wolfgang Ulbrich 2015-03-03 14:45:23 UTC
fixed upower scratch build
http://koji.fedoraproject.org/koji/taskinfo?taskID=9132203

Comment 25 leigh scott 2015-03-04 16:53:13 UTC
It's also fixes my issue here.

Comment 26 Wolfgang Ulbrich 2015-03-04 17:05:38 UTC
Thanks for testing the fix Leigh.
Richard, can you please review the patch?
This fixes also https://bugzilla.redhat.com/show_bug.cgi?id=1151628
and is testable with it.

Comment 27 Wolfgang Ulbrich 2015-03-13 13:43:56 UTC
Patch is upstreamed, see http://cgit.freedesktop.org/upower/commit/?id=2510148b16
Can you please rebuild upower with upstream commit ?

Comment 28 Stephen Haffly 2015-03-16 00:23:45 UTC
Another user experienced a similar problem:

1. start "upower --monitor-detail"
2. upower abended with this error.

The reason for monitoring is to try to figure out why a CyberPower BRG100ABRLCD is having continuous disconnects and reconnects. This happens about every 10 seconds.

reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        upower --monitor-detail
crash_function: g_variant_unref
executable:     /usr/bin/upower
kernel:         3.18.9-200.fc21.x86_64
package:        upower-0.99.2-1.fc21
reason:         upower killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            0

Comment 29 Rex Dieter 2015-03-18 11:18:35 UTC
I can look into helping backport the aforementioned upstream fixes into fedora packaging.

Comment 30 Fedora Update System 2015-03-18 13:34:57 UTC
upower-0.99.2-4.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/upower-0.99.2-4.fc22

Comment 31 Fedora Update System 2015-03-18 13:36:02 UTC
upower-0.99.2-4.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/upower-0.99.2-4.fc21

Comment 32 Wolfgang Ulbrich 2015-03-18 17:29:54 UTC
*** Bug 1196643 has been marked as a duplicate of this bug. ***

Comment 33 Fedora Update System 2015-03-19 18:43:38 UTC
Package upower-0.99.2-4.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing upower-0.99.2-4.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4191/upower-0.99.2-4.fc21
then log in and leave karma (feedback).

Comment 34 Fedora Update System 2015-03-21 04:53:45 UTC
upower-0.99.2-4.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 35 Fedora Update System 2015-03-26 22:10:01 UTC
upower-0.99.2-4.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 36 Stephen Haffly 2015-03-27 00:05:04 UTC
This update appears to have resolved the issues for me. Thanks. As for the UPS (mentioned in comment #28), that appears to have been an issue with the UPS itself, which will soon be returned to and replaced by CyberPower.


Note You need to log in before you can comment on or make changes to this bug.