Description of problem: logged in after restoring a window$ 7 system image backup. crashed? Version-Release number of selected component: udisks2-2.0.1-1.fc18 Additional info: backtrace_rating: 4 cmdline: /usr/lib/udisks2/udisksd --no-debug core_backtrace: executable: /usr/lib/udisks2/udisksd kernel: 3.7.9-201.fc18.x86_64 uid: 0
Created attachment 702042 [details] File: backtrace
Created attachment 702043 [details] File: cgroup
Created attachment 702044 [details] File: dso_list
Created attachment 702045 [details] File: environ
Created attachment 702046 [details] File: limits
Created attachment 702047 [details] File: maps
Created attachment 702048 [details] File: open_fds
Created attachment 702049 [details] File: proc_pid_status
Created attachment 702050 [details] File: var_log_messages
NULL pointer deref: > 661 if (error->domain != POLKIT_ERROR) Apparently polkit_authority_check_authorization_sync() returned NULL and didn't set an error --> reassigning to polkit.
Looking at polkit_authority_check_authorization_sync(), there's a bunch of asserts that only returns a value without setting GError. Either docs need to be clarified or the checks changed. The problem could very well come from the wrapped async call.
(In reply to comment #11) > Looking at polkit_authority_check_authorization_sync(), there's a bunch of > asserts that only returns a value without setting GError. Either docs need > to be clarified or the checks changed. No, these asserts check interface preconditions; AFAICS this is an established coding style for GLib applications. > The problem could very well come from the wrapped async call. Yes; from a quick look I can't find any unhandled errors, but there might be invalid assumptions (e.g. a call to g_variant_get_child_value() without checking the format first). Malar, can you reproduce the crash?
Bug 866718 is actually master bug but let's deal with the issue here.
From looking at various backtraces, it is very frequent (but not universal) for two different threads to be stopped at the same instruction (can two threads really crash at the same time?), often when there are two parallel "mount" operations being authorized (two partitions on the same device, or two devices). There is also a crash that gets PM data instead of mounting, though. I have tried > while :; do (udisksctl mount --block-device /dev/sdb1 & udisksctl mount --block-device /dev/sdb2; wait); (udisksctl unmount --block-device /dev/sdb1 & udisksctl unmount --block-device /dev/sdb2; wait); done even restarting udisks in the meantime, and so far no luck.
(In reply to comment #12) > (In reply to comment #11) > > Looking at polkit_authority_check_authorization_sync(), there's a bunch of > > asserts that only returns a value without setting GError. Either docs need > > to be clarified or the checks changed. > > No, these asserts check interface preconditions; AFAICS this is an > established coding style for GLib applications. Right, there would likely be some assertion failure printed on console but ABRT doesn't provide such information. Reading polkit sources I can't find any obvious problem. Tried to reproduce the problem with any luck.
(In reply to comment #15) > (In reply to comment #12) > > (In reply to comment #11) > > > Looking at polkit_authority_check_authorization_sync(), there's a bunch of > > > asserts that only returns a value without setting GError. Either docs need > > > to be clarified or the checks changed. > > > > No, these asserts check interface preconditions; AFAICS this is an > > established coding style for GLib applications. > > Right, there would likely be some assertion failure printed on console but > ABRT doesn't provide such information. "On console" means that systemd should be recording them and be able to display them via (systemctl status udisks2), shouldn't it? Having a bug repoter that can reliably reproduce the crash would be really helpful.
*** This bug has been marked as a duplicate of bug 866718 ***