Red Hat Bugzilla – Bug 834359
Lenovo X220 fails to suspend with segfault at upowerd
Last modified: 2013-07-09 11:48:21 EDT
Description of problem:
[21204.246410] usb 2-1.2: new high-speed USB device number 3 using ehci_hcd
[21204.336535] usb 2-1.2: New USB device found, idVendor=05ac, idProduct=12a0
[21204.336544] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[21204.336551] usb 2-1.2: Product: iPhone
[21204.336555] usb 2-1.2: Manufacturer: Apple Inc.
[21204.336559] usb 2-1.2: SerialNumber: 5f69d3a91b28fe9ede1b472a05e3a376c3782706
[21204.935242] ipheth 2-1.2:4.2: Apple iPhone USB Ethernet device attached
[21204.935847] usbcore: registered new interface driver ipheth
[21204.956043] ADDRCONF(NETDEV_UP): eth0: link is not ready
[21205.399472] upowerd: segfault at 0 ip 0000003fa5906720 sp 00007fff8334c838 error 4 in libc-2.15.so[3fa5800000+1ac000]
[21205.858743] iphone-set-info: segfault at 0 ip 0000003fa5906720 sp 00007fff3e732608 error 4 in libc-2.15.so[3fa5800000+1ac000]
[28726.921884] upowerd: segfault at 0 ip 0000003fa5906720 sp 00007fffefbb7398 error 4 in libc-2.15.so[3fa5800000+1ac000]
[28750.074393] upowerd: segfault at 0 ip 0000003fa5906720 sp 00007fffe605c2e8 error 4 in libc-2.15.so[3fa5800000+1ac000]
[28792.211545] upowerd: segfault at 0 ip 0000003fa5906720 sp 00007fffdc1271c8 error 4 in libc-2.15.so[3fa5800000+1ac000]
Version-Release number of selected component (if applicable):
Suspend F17 on x220.
Steps to Reproduce:
segfault, screen is locked
Can you get a backtrace please. Thanks.
Not sure if this helps, but this problem doesn't occur on a ThinkPad X230.
It appears to be this bug:
When an iOS device is connected, upowerd pulls in libimobiledevice. If XDG_CONFIG_HOME is not set in the environment, it tries to copy the value of HOME instead. However, in the systemd environment, HOME is null and strcpy() causes a SEGV. It isn't checking if HOME is null.
This isn't specific to the Thinkad; it should happen on any system with an iOS device plugged in. libimobiledevice needs to be updated to correctly handle a null HOME.
Here's the backtrace from F17:
#0 __stpcpy_chk () at ../sysdeps/x86_64/strcpy_chk.S:71
#1 0x00007f9c643f225c in strcpy (__src=<optimized out>, __dest=
0x7f9c64602600 "") at /usr/include/bits/string3.h:105
#2 userpref_get_config_dir () at userpref.c:128
#3 userpref_get_config_dir () at userpref.c:105
#4 0x00007f9c643f25d4 in userpref_get_host_id (host_id=host_id@entry=
0x7fff05ef3fb0) at userpref.c:406
#5 0x00007f9c643f5c1d in lockdownd_client_new_with_handshake (
device=<optimized out>, client=client@entry=0x7fff05ef4058,
label=label@entry=0x41bb5d "upower") at lockdown.c:717
#6 0x0000000000412cbb in up_device_idevice_coldplug (device=
0x11473e0 [UpDeviceIdevice]) at up-device-idevice.c:105
#7 0x000000000040b6ab in up_device_coldplug (device=device@entry=
0x11473e0 [UpDeviceIdevice], daemon=<optimized out>,
native=<optimized out>) at up-device.c:548
#8 0x0000000000411861 in up_backend_device_new (native=
0x113b720 [GUdevDevice], backend=0x112e4f0 [UpBackend]) at up-backend.c:128
#9 up_backend_device_add (backend=backend@entry=0x112e4f0 [UpBackend], native=
0x113b720 [GUdevDevice]) at up-backend.c:229
#10 0x00000000004120db in up_backend_coldplug (backend=0x112e4f0 [UpBackend],
daemon=daemon@entry=0x1122010 [UpDaemon]) at up-backend.c:324
#11 0x0000000000408e0f in up_daemon_startup (daemon=daemon@entry=
0x1122010 [UpDaemon]) at up-daemon.c:753
#12 0x0000000000406d77 in main (argc=1, argv=0x7fff05ef4408) at up-main.c:289
I previously filed a similar bug which describes the same iPhone issue on a ThinkPad X230: https://bugzilla.redhat.com/show_bug.cgi?id=836399
This is a bug in lockdownd.
*** Bug 836399 has been marked as a duplicate of this bug. ***
Any ETA for a fix?
I'm not sure what lockdownd is and what it has with libimobiledevice tbh
(In reply to comment #8)
> I'm not sure what lockdownd is and what it has with libimobiledevice tbh
It's a library for accessing Apple hardware.
The analysis of the problem is correct, the problem is indeed when iOS device is connected. Thanks guys.
Is there any walkaround for this?
On my laptop. upowerd crashes. I loss battery indication. Also loss the ability to suspend the laptop.
Aug 4 22:20:05 THINK-MX upowerd: (upowerd:4739): UPower-Linux-WARNING **: energy_full (48.190000) is greater than energy_full_design (47.520000)
Aug 4 22:20:06 THINK-MX kernel: [ 1671.609524] upowerd: segfault at 0 ip 0000003d3fb06700 sp 00007fff94d74838 error 4 in libc-2.15.so[3d3fa00000+1ac000]
Aug 4 22:20:06 THINK-MX abrtd: Directory 'ccpp-2012-08-04-22:20:06-4739' creation detected
Aug 4 22:20:06 THINK-MX abrt: Saved core dump of pid 4739 (/usr/libexec/upowerd) to /var/spool/abrt/ccpp-2012-08-04-22:20:06-4739 (18333696 bytes)
Aug 4 22:20:06 THINK-MX systemd: upower.service: main process exited, code=dumped, status=11
Aug 4 22:20:06 THINK-MX systemd: Unit upower.service entered failed state.
Aug 4 22:20:06 THINK-MX abrtd: Duplicate: core backtrace
Aug 4 22:20:06 THINK-MX abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-08-04-21:24:22-867
Aug 4 22:20:06 THINK-MX abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-08-04-21:24:22-867
Aug 4 22:20:06 THINK-MX abrtd: Deleting problem directory ccpp-2012-08-04-22:20:06-4739 (dup of ccpp-2012-08-04-21:24:22-867)
You can add the HOME environment to the unit file /usr/lib/systemd/system/upower.service:
Description=Daemon for power management
# ###Workaround, %h is systemd's user's home
# We pull this in by graphical.target instead of waiting for the bus
# activation, to speed things up a little: gdm uses this anyway so it is nice
# if it is already around when gdm wants to use it and doesn't have to wait for
After editing you need to either reboot or run "systemctl --system daemon-reload" and "systemctl start upower.service".
Incorporating the upstream fix is the ultimate solution, of course.
With Environment=HOME=%h which I think gives HOME=/root, It causes iphone-set-info to crash due to https://bugzilla.redhat.com/show_bug.cgi?id=733701
Nevertheless, it keeps upowerd from crashing.
libimobiledevice-1.1.4-4.fc18 has been submitted as an update for Fedora 18.
Can we have this update for f17 as well? This bug is against that release, and I'd personally love seeing it fixed there, as I use it.
Bastien, will we see this libimobiledevice update for f17?
Jon, I took the src.rpm from f18 update and patched f17 rpm by my self. You can try to do this for the moment as it seems the maintainer is currently not available.
I may do that short term. Bastien, also, I'm a provenpackager and could do this for you if you'd like asssistance.
I did my best to try and compile the package for Fedora 17, but got hit by:
I'd personally nuke the Cython bindings, nothing useful uses them.
Changelog says that was disabled in -3, so I'd think -4 should work.
I tried this on 17, and it builds and fixes that crash. It exposed a crash in gtkpod, but that's good. I'll commit and build tomorrow unless you object, or approve sooner.
libimobiledevice-1.1.4-4.fc17 has been submitted as an update for Fedora 17.
The new build fixes it for me. Thanks!
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libimobiledevice-1.1.4-4.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
This has been pushed to stable
*** Bug 836764 has been marked as a duplicate of this bug. ***