Bug 860572

Summary: [abrt] gphoto2-2.5.0-2.fc18: reap_for_handle: Process /usr/bin/gphoto2 was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Harald Hoyer <harald>
Component: libusbxAssignee: Hans de Goede <hdegoede>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: hdegoede, jnovy, jvcelak, lucilanga, rhbugs
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:3f7f0ca7bc17e8bedbb92dc4f593fb4a02dd7092
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-26 14:10:31 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: core_backtrace
none
File: backtrace
none
File: limits
none
File: cgroup
none
File: maps
none
File: dso_list
none
File: open_fds none

Description Harald Hoyer 2012-09-26 08:12:27 UTC 
Description of problem:
$ gphoto2  --capture-image-and-download

*** Error ***      
PTP-I/O Error

Photo was captured, then gphoto2 crashed.



Version-Release number of selected component:
gphoto2-2.5.0-2.fc18

Additional info:
libreport version: 2.0.13
abrt_version:   2.0.12
backtrace_rating: 4
cmdline:        gphoto2 --capture-image-and-download
crash_function: reap_for_handle
kernel:         3.6.0-0.rc4.git0.1.fc18.x86_64

truncated backtrace:
:Thread no. 1 (10 frames)
: #0 reap_for_handle at os/linux_usbfs.c
: #1 op_handle_events at os/linux_usbfs.c
: #2 handle_events at io.c
: #3 libusb_handle_events_timeout_completed at io.c
: #4 libusb_handle_events_completed at io.c
: #5 do_sync_bulk_transfer at sync.c
: #6 libusb_bulk_transfer at sync.c
: #7 usb_bulk_io at core.c
: #8 usb_bulk_write at core.c
: #9 gp_port_usb_write at usb/libusb.c
Comment 1 Harald Hoyer 2012-09-26 08:12:30 UTC 
Created attachment 617441 [details]
File: core_backtrace
Comment 2 Harald Hoyer 2012-09-26 08:12:33 UTC 
Created attachment 617442 [details]
File: backtrace
Comment 3 Harald Hoyer 2012-09-26 08:12:35 UTC 
Created attachment 617443 [details]
File: limits
Comment 4 Harald Hoyer 2012-09-26 08:12:37 UTC 
Created attachment 617444 [details]
File: cgroup
Comment 5 Harald Hoyer 2012-09-26 08:12:40 UTC 
Created attachment 617445 [details]
File: maps
Comment 6 Harald Hoyer 2012-09-26 08:12:42 UTC 
Created attachment 617446 [details]
File: dso_list
Comment 7 Harald Hoyer 2012-09-26 08:12:44 UTC 
Created attachment 617447 [details]
File: open_fds
Comment 8 Harald Hoyer 2012-09-26 08:13:27 UTC 
Camera was a Canon 5Dmk3
Comment 9 Jindrich Novy 2012-09-26 09:04:41 UTC 
Assuming it is not caused by a gphoto2/libgphoto2 bad API call given the segfault occurs seven levels deep within libusbx.

Suspecting also libusbx because of its rapid development recently. Looking into upstream's trac tickets, some segfaults there might be possible.
Comment 10 Hans de Goede 2012-09-26 11:24:50 UTC 
Harald,

Is this reproducable? And if so can you still reproduce it with libusbx-1.0.14 (just build) ?

Regards,

Hans
Comment 11 Harald Hoyer 2012-09-26 12:06:54 UTC 
(In reply to comment #10)
> Harald,
> 
> Is this reproducable? And if so can you still reproduce it with
> libusbx-1.0.14 (just build) ?
> 
> Regards,
> 
> Hans


Not reproducable :-/
Comment 12 Hans de Goede 2012-09-26 14:10:31 UTC 
(In reply to comment #11)
> (In reply to comment #10)
> > Harald,
> > 
> > Is this reproducable? And if so can you still reproduce it with
> > libusbx-1.0.14 (just build) ?
> > 
> > Regards,
> > 
> > Hans
> 
> 
> Not reproducable :-/

Bummer. I've looked at the backtrace and it is weird, without a reproducer I cannot make
anything more out of it, then that it is weird. So I'm going to close this as not enough info.

Do let me know if you see this again please!