Bug 915077

Summary: [abrt] udisks2-2.0.1-1.fc18: Process /usr/lib/udisks2/udisksd was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Malar Kannan <malarkannan.p>
Component: polkitAssignee: Miloslav Trmač <mitr>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: mitr, tbzatek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:12b3eb6ceb8ef04f72b45b0c358ce5f7c9d0ea40
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-09 15:42:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Malar Kannan 2013-02-24 16:09:40 UTC 
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
Comment 1 Malar Kannan 2013-02-24 16:09:50 UTC 
Created attachment 702042 [details]
File: backtrace
Comment 2 Malar Kannan 2013-02-24 16:09:55 UTC 
Created attachment 702043 [details]
File: cgroup
Comment 3 Malar Kannan 2013-02-24 16:10:00 UTC 
Created attachment 702044 [details]
File: dso_list
Comment 4 Malar Kannan 2013-02-24 16:10:06 UTC 
Created attachment 702045 [details]
File: environ
Comment 5 Malar Kannan 2013-02-24 16:10:10 UTC 
Created attachment 702046 [details]
File: limits
Comment 6 Malar Kannan 2013-02-24 16:10:16 UTC 
Created attachment 702047 [details]
File: maps
Comment 7 Malar Kannan 2013-02-24 16:10:21 UTC 
Created attachment 702048 [details]
File: open_fds
Comment 8 Malar Kannan 2013-02-24 16:10:27 UTC 
Created attachment 702049 [details]
File: proc_pid_status
Comment 9 Malar Kannan 2013-02-24 16:10:32 UTC 
Created attachment 702050 [details]
File: var_log_messages
Comment 10 Tomáš Bžatek 2013-03-22 15:13:08 UTC 
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.
Comment 11 Tomáš Bžatek 2013-03-22 15:18:06 UTC 
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.
Comment 12 Miloslav Trmač 2013-03-22 16:33:22 UTC 
(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?
Comment 13 Tomáš Bžatek 2013-03-22 16:41:36 UTC 
Bug 866718 is actually master bug but let's deal with the issue here.
Comment 14 Miloslav Trmač 2013-03-23 01:14:01 UTC 
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.
Comment 15 Tomáš Bžatek 2013-03-26 14:44:37 UTC 
(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.
Comment 16 Miloslav Trmač 2013-03-26 14:48:47 UTC 
(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.
Comment 17 Miloslav Trmač 2013-07-09 15:42:30 UTC 

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