Bug 648777

Summary: [abrt] rhythmbox-0.12.8-4.fc13: Process /usr/bin/rhythmbox was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Darek <darsliwa>
Component: rhythmboxAssignee: Bastien Nocera <bnocera>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: bnocera
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:d3988439c0657f2defa1c6a337c742622f5952b9
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-09 14:07:32 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

Description Darek 2010-11-02 04:52:11 UTC 
abrt version: 1.1.13
architecture: x86_64
Attached file: backtrace
cmdline: /usr/bin/rhythmbox
component: rhythmbox
crash_function: LIBMTP_Send_Track_From_File_Descriptor
executable: /usr/bin/rhythmbox
kernel: 2.6.34.7-61.fc13.x86_64
package: rhythmbox-0.12.8-4.fc13
rating: 4
reason: Process /usr/bin/rhythmbox was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Goddard)
time: 1288672758
uid: 500

How to reproduce
-----
1. I run RythmBox
2. I connected the Samsung Galaxy S smartphone (Android) in MTP mode. RythmBox recognized Samsung as unknown device but allowed file copying.
3. I started to copy randomly selected music files (mp3). The first file was copied (at least this is what GUI showed, because no real file was found on Samsung)
4. Once the first file was copied, RythmBox froze for several seconds and then crashed.
Comment 1 Darek 2010-11-02 04:52:14 UTC 
Created attachment 457054 [details]
File: backtrace
Comment 2 Karel Klíč 2010-11-09 14:07:32 UTC 

*** This bug has been marked as a duplicate of bug 611109 ***
Comment 3 Karel Klíč 2010-11-09 14:07:32 UTC 
This bug appears to have been filled using a buggy version of ABRT, because
it contains a backtrace which is a duplicate of backtrace from bug #611109.

Sorry for the inconvenience.