Bug 1010229

Summary: [abrt] gvfs-mtp-1.16.3-2.el7: list_del: Process /usr/libexec/gvfsd-mtp was killed by signal 11 (SIGSEGV)
Product: Red Hat Enterprise Linux 7 Reporter: Vladimir Benes <vbenes>
Component: gvfsAssignee: Ondrej Holy <oholy>
Status: CLOSED NEXTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:0ecf987241e17a3d86b9de51fc2f9a70abc8d4d1
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-08 14:34:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Vladimir Benes 2013-09-20 10:17:48 UTC 
Version-Release number of selected component:
gvfs-mtp-1.16.3-2.el7

Additional info:
reporter:       libreport-2.1.7
backtrace_rating: 4
cmdline:        /usr/libexec/gvfsd-mtp --spawner :1.3 /org/gtk/gvfs/exec_spaw/5
crash_function: list_del
executable:     /usr/libexec/gvfsd-mtp
kernel:         3.10.0-22.el7.x86_64
runlevel:       N 5
type:           CCpp
uid:            1004

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 list_del at libusbi.h:119
 #1 usbi_handle_transfer_completion at io.c:1460
 #2 usbi_handle_disconnect at io.c:2448
 #3 op_handle_events at os/linux_usbfs.c:2501
 #4 handle_events at io.c:1941
 #5 libusb_handle_events_timeout_completed at io.c:2021
 #6 libusb_handle_events_completed at io.c:2120
 #7 do_sync_bulk_transfer at sync.c:183
 #8 libusb_bulk_transfer at sync.c:272
 #9 ptp_usb_event at libusb1-glue.c:1557
Comment 1 Vladimir Benes 2013-09-20 10:17:51 UTC 
Created attachment 800410 [details]
File: backtrace
Comment 2 Vladimir Benes 2013-09-20 10:17:54 UTC 
Created attachment 800411 [details]
File: cgroup
Comment 3 Vladimir Benes 2013-09-20 10:17:56 UTC 
Created attachment 800412 [details]
File: core_backtrace
Comment 4 Vladimir Benes 2013-09-20 10:17:59 UTC 
Created attachment 800414 [details]
File: dso_list
Comment 5 Vladimir Benes 2013-09-20 10:18:02 UTC 
Created attachment 800416 [details]
File: environ
Comment 6 Vladimir Benes 2013-09-20 10:18:04 UTC 
Created attachment 800417 [details]
File: exploitable
Comment 7 Vladimir Benes 2013-09-20 10:18:07 UTC 
Created attachment 800418 [details]
File: limits
Comment 8 Vladimir Benes 2013-09-20 10:18:09 UTC 
Created attachment 800419 [details]
File: maps
Comment 9 Vladimir Benes 2013-09-20 10:18:12 UTC 
Created attachment 800420 [details]
File: open_fds
Comment 10 Vladimir Benes 2013-09-20 10:18:15 UTC 
Created attachment 800421 [details]
File: proc_pid_status
Comment 11 Vladimir Benes 2013-09-20 10:18:17 UTC 
Created attachment 800422 [details]
File: var_log_messages
Comment 13 RHEL Program Management 2014-03-22 06:38:29 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 15 Ondrej Holy 2015-03-31 11:16:42 UTC 
I suppose you hard unplug the device without clean unmount, are you able to reproduce it?

There is probably bug in libusb, because gvfs just waiting for LIBMTP_Read_Event, libmtp is also waiting for libusb_bulk_transfer, and libusb tries to remove entry from the list, because it received LIBUSB_TRANSFER_NO_DEVICE, however it caused SEGFAULT in Thread 1 (was the entry already removed?).

Maybe there is some race with Thread 5, which is already using libusb, however it waits on mutex in time of crash...
Comment 17 Vladimir Benes 2015-04-08 14:34:34 UTC 
It was done by clicking unmount in nautilus. I've tried the same in rebase 3.14 gnome and there is not problem. Will reopen if it occurs again.