udisksd crashed with SIGSEGV in wait_for_loop_object()

Bug #1128275 reported by Jaydip Guha on 2013-02-17
68
This bug affects 13 people
Affects Status Importance Assigned to Milestone
udisks
Fix Released
Critical
udisks2 (Ubuntu)
Medium
Unassigned

Bug Description

I guess I reported the udisk related crash before. it is a problem since 12.10. once crash happens all unmounted volumes appear on the sidebar and clutter.

ProblemType: Crash
DistroRelease: Ubuntu 13.04
Package: udisks2 2.0.1-1
ProcVersionSignature: Ubuntu 3.8.0-6.13-generic 3.8.0-rc7
Uname: Linux 3.8.0-6-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.8-0ubuntu4
Architecture: amd64
CustomUdevRuleFiles: 10-vboxdrv.rules
Date: Sun Feb 17 10:41:07 2013
ExecutablePath: /usr/lib/udisks2/udisksd
InstallationDate: Installed on 2012-11-11 (98 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MachineType: Gigabyte Technology Co., Ltd. GA-MA785GMT-USB3
MarkForUpload: True
ProcCmdline: /usr/lib/udisks2/udisksd --no-debug
ProcEnviron:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-6-generic root=UUID=fac5d218-94e9-4165-8f79-3c5746d2fd1f ro plymouth:debug splash quiet drm.debug=0xe
SegvAnalysis:
 Segfault happened at: 0x42e5fd: mov (%rax),%ebp
 PC (0x0042e5fd) ok
 source "(%rax)" (0x00000000) not located in a known VMA region (needed readable region)!
 destination "%ebp" ok
 Stack memory exhausted (SP below stack segment)
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: udisks2
StacktraceTop:
 ?? ()
 ?? ()
 ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
 ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
 g_cclosure_marshal_generic () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
Title: udisksd crashed with SIGSEGV in ffi_call_unix64()
UpgradeStatus: Upgraded to raring on 2013-01-27 (20 days ago)
UserGroups:

dmi.bios.date: 01/04/2010
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F1
dmi.board.name: GA-785GMT-USB3
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF1:bd01/04/2010:svnGigabyteTechnologyCo.,Ltd.:pnGA-MA785GMT-USB3:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-785GMT-USB3:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-MA785GMT-USB3
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

Jaydip Guha (guha-jaydip) wrote :

StacktraceTop:
 wait_for_loop_object (daemon=0x7f9484000020, user_data=0xffffffff) at udiskslinuxmanager.c:222
 gnu_dev_minor (__dev=<optimized out>) at /usr/include/x86_64-linux-gnu/sys/sysmacros.h:52
 udisks_state_check_mounted_fs_entry (devs_to_clean=0x647628, value=0x0, state=0x7f9484001100) at udisksstate.c:687
 udisks_state_check_mounted_fs (state=0x7f9484001100, devs_to_clean=0x647628) at udisksstate.c:802
 ?? ()

Changed in udisks2 (Ubuntu):
importance: Undecided → Medium
summary: - udisksd crashed with SIGSEGV in ffi_call_unix64()
+ udisksd crashed with SIGSEGV in wait_for_loop_object()
tags: removed: need-amd64-retrace
Martin Pitt (pitti) on 2013-03-25
information type: Private → Public
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in udisks2 (Ubuntu):
status: New → Confirmed
Download full text (9.0 KiB)

In Fedora 20 when trying to mount an archive using the Archive Mounter, several users reported a crash. I get it 100% of times when trying to mount a LiveCD of F20 Alpha.

udisks2-2.1.1-1.fc20

https://bugzilla.redhat.com/show_bug.cgi?id=1007223

Thread 1 (Thread 0x7fdc82480700 (LWP 5888)):
#0 0x00007fdc84fbb6ff in g_dbus_object_get_interface (object=0x0, interface_name=0x7fdc85296ab1 "org.freedesktop.UDisks2.Block") at gdbusobject.c:144
        iface = <optimized out>
        __PRETTY_FUNCTION__ = "g_dbus_object_get_interface"
#1 0x00007fdc8528f2b3 in udisks_object_peek_block (object=0x0) at udisks-generated.c:31007
        ret = <optimized out>
#2 0x00007fdc86358e37 in wait_for_loop_object (daemon=0x7fdc879cd640, user_data=0x7fdc8247d500) at udiskslinuxmanager.c:233
        ret = 0x0
        object = 0x0
        block = <optimized out>
        loop = <optimized out>
        device = 0x0
        dir = <optimized out>
#3 0x00007fdc8633ba3f in udisks_daemon_wait_for_object_sync (daemon=0x7fdc879cd640, wait_func=wait_func@entry=0x7fdc86358df0 <wait_for_loop_object>, user_data=user_data@entry=0x7fdc8247d500, user_data_free_func=user_data_free_func@entry=0x0, timeout_seconds=timeout_seconds@entry=10, error=error@entry=0x7fdc8247d4e8) at udisksdaemon.c:884
        ret = <optimized out>
        data = {context = 0x0, loop = 0x0, timed_out = 0}
        __PRETTY_FUNCTION__ = "udisks_daemon_wait_for_object_sync"
#4 0x00007fdc8635a002 in handle_loop_setup (object=0x7fdc74005ea0, invocation=0x7fdc7400ae70, fd_list=<optimized out>, fd_index=<optimized out>, options=<optimized out>) at udiskslinuxmanager.c:450
        manager = 0x7fdc74005ea0
        error = 0x0
        fd_num = <optimized out>
        fd = 15
        proc_path = "/proc/1552/fd/15\000\000\000\000\000\000\000\000\002", '\000' <repeats 31 times>, "\002\000\000\000\000\000\000"
        path = "/home/rizvan/Downloads/Fedora-20-Nightly-x86_64-Live-desktop-20130828.08-1.iso", '\000' <repeats 674 times>...
        loop_fd = 17
        loop_control_fd = <optimized out>
        allocated_loop_number = <optimized out>
        loop_device = 0x7fdc7401c130 "/dev/loop0"
        li64 = {lo_device = 0, lo_inode = 0, lo_rdevice = 0, lo_offset = 0, lo_sizelimit = 0, lo_number = 0, lo_encrypt_type = 0, lo_encrypt_key_size = 0, lo_flags = 9, lo_file_name = "/home/rizvan/Downloads/Fedora-20-Nightly-x86_64-Live-desktop-20", lo_crypt_name = '\000' <repeats 63 times>, lo_encrypt_key = '\000' <repeats 31 times>, lo_init = {0, 0}}
        loop_object = 0x0
        option_read_only = 1
        option_no_part_scan = 0
        option_offset = 0
        option_size = 0
        caller_uid = 1000
        fd_statbuf = {st_dev = 64773, st_ino = 262980, st_nlink = 1, st_mode = 33184, st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 1044381696, st_blksize = 4096, st_blocks = 2039816, st_atim = {tv_sec = 1377762146, tv_nsec = 3029282}, st_mtim = {tv_sec = 1377762075, tv_nsec = 203231809}, st_ctim = {tv_sec = 1377762096, tv_nsec = 131876774}, __unused = {0, 0, 0}}
        fd_statbuf_valid = <optimized out>
        wait_data = {loop_device = 0x7fdc7401c130 "/dev/loop0", path = 0x7fdc8247d6d0 "/home/rizvan...

Read more...

Same issue here, I can mount the iso image files by using
mount -t iso9660 -o loop /path/image.iso /mnt/iso

But the problem when I try to mount the ISO files from GUI, I tried it with 'dolphin' and 'thunar', the same issue, it tells that:

Error attaching disk image: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) (g-dbus-error-quark, 4)

And:

Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
QDBusConnection: name 'org.freedesktop.UDisks2' had owner '' but we thought it was ':1.306'

I use Fedora 20 as well.

Similar issue with Debian sid.

I think it might be a race, as wait_for_loop_object() will try and get an object that doesn't exist yet.

udisks_daemon_find_block_by_device_file() fails and returns NULL.

Starting "Disks" after trying to mount it will work (whatever you tried to mount is now mounted), likely because the system has settled and the device is finally mounted.

Created attachment 91828
proposed patch

From a quick look, would this simple test fix the issue?

If for some reason we're unable to get a UDisksObject instance, just bail out and let udisks_daemon_wait_for_object_sync() continue with the loop and call the wait_func again after a short break. Hopefully the object we're looking for will arrive until then.

Comment on attachment 91828
proposed patch

Review of attachment 91828:
-----------------------------------------------------------------

I've tested this patch and it fixes bug.
Tested-by: Igor Gnatenko <email address hidden>

Comment on attachment 91828
proposed patch

Review of attachment 91828:
-----------------------------------------------------------------

Yeah, looks good to me - thanks! Please commit it to master.

...and please prepare us a backport at some point. ;-)

Comment on attachment 91828
proposed patch

Where should I copy this patch? and how?

Looks good to me, I committed Tomas' patch to http://cgit.freedesktop.org/udisks/commit/?id=f6bce1 . Thanks!

Martin Pitt (pitti) wrote :

Fixed in 2.1.2

Changed in udisks2 (Ubuntu):
status: Confirmed → Fix Committed
Changed in udisks:
importance: Unknown → Critical
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udisks2 - 2.1.2-1

---------------
udisks2 (2.1.2-1) unstable; urgency=low

  [ Martin Pitt ]
  * New upstream release:
    - Add exfat support (Closes: #720695)
    - Fix crash when waiting for loop device (LP: #1128275)
    - Use dosfstools instead of mtools
    - Add polkit authorization variables for removable media
    - Hide more rescue partitions
  * Drop dosfslabel.patch, fixed upstream.
  * Add Recommends: gdisk, as we need it for manipulating GPT partition tables
    through sgdisk. (LP: #1080745)
  * Bump Standards-Version to 3.9.5. No changes necessary.

  [ Colin Watson ]
  * Use dh-autoreconf to update libtool macros for new ports.
    (Closes: #732287)

  [ Andreas Henriksson ]
  * Add parted dependency. (Closes: #720491)

 -- Martin Pitt <email address hidden> Tue, 14 Jan 2014 10:04:52 +0100

Changed in udisks2 (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.