Bug 1150691

Summary: [abrt] easytag: Cddb_Album_List_Set_Row_Appearance(): easytag killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Bogdan Mințoi <mintoi.bogdan>
Component: easytagAssignee: David King <amigadave>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: amigadave, matthias, mintoi.bogdan
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/e6bc77c730de680cf908bbd49647b6a14e0e2ded
Whiteboard: abrt_hash:16332964ded68d21a678f35f467ade140a12bc60
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-08 20:27:27 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: 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 Bogdan Mințoi 2014-10-08 17:11:29 UTC 
Version-Release number of selected component:
easytag-2.2.4-1.fc21

Additional info:
reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        easytag
crash_function: Cddb_Album_List_Set_Row_Appearance
executable:     /usr/bin/easytag
kernel:         3.16.3-302.fc21.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 Cddb_Album_List_Set_Row_Appearance at src/cddb.c:3836
 #1 Cddb_Get_Album_Tracks_List at src/cddb.c:3808
 #2 Cddb_Get_Album_Tracks_List_CB at src/cddb.c:3448
 #7 _gtk_tree_selection_internal_select_node at gtktreeselection.c:1594
 #8 gtk_tree_view_real_set_cursor at gtktreeview.c:13287
 #9 gtk_tree_view_multipress_gesture_pressed at gtktreeview.c:3287
 #10 ffi_call_unix64 at ../src/x86/unix64.S:76
 #11 ffi_call at ../src/x86/ffi64.c:525
 #12 g_cclosure_marshal_generic_va at gclosure.c:1541
 #13 _g_closure_invoke_va at gclosure.c:831

Potential duplicate: bug 1123149
Comment 1 Bogdan Mințoi 2014-10-08 17:11:32 UTC 
Created attachment 945108 [details]
File: backtrace
Comment 2 Bogdan Mințoi 2014-10-08 17:11:34 UTC 
Created attachment 945109 [details]
File: cgroup
Comment 3 Bogdan Mințoi 2014-10-08 17:11:35 UTC 
Created attachment 945110 [details]
File: core_backtrace
Comment 4 Bogdan Mințoi 2014-10-08 17:11:36 UTC 
Created attachment 945111 [details]
File: dso_list
Comment 5 Bogdan Mințoi 2014-10-08 17:11:38 UTC 
Created attachment 945112 [details]
File: environ
Comment 6 Bogdan Mințoi 2014-10-08 17:11:39 UTC 
Created attachment 945113 [details]
File: exploitable
Comment 7 Bogdan Mințoi 2014-10-08 17:11:40 UTC 
Created attachment 945114 [details]
File: limits
Comment 8 Bogdan Mințoi 2014-10-08 17:11:42 UTC 
Created attachment 945115 [details]
File: maps
Comment 9 Bogdan Mințoi 2014-10-08 17:11:43 UTC 
Created attachment 945116 [details]
File: open_fds
Comment 10 Bogdan Mințoi 2014-10-08 17:11:44 UTC 
Created attachment 945117 [details]
File: proc_pid_status
Comment 11 Bogdan Mințoi 2014-10-08 17:11:45 UTC 
Created attachment 945118 [details]
File: var_log_messages
Comment 12 David King 2014-10-08 17:18:59 UTC 
Hi, do you have any idea of the steps to reproduce this bug? As you can see from bug 1123149 (where the stack trace looks very similar) I cannot reproduce it, so any hints as to some way to reliably reproduce the problem would be really helpful.
Comment 13 Bogdan Mințoi 2014-10-08 19:44:43 UTC 
(In reply to David King from comment #12)
> Hi, do you have any idea of the steps to reproduce this bug? As you can see
> from bug 1123149 (where the stack trace looks very similar) I cannot
> reproduce it, so any hints as to some way to reliably reproduce the problem
> would be really helpful.

Sure.
My music files (mp3, ogg, etc.) are stored in ~/Music. Gnome-Music was playing them nicely. After I downloaded some more files, i created 2 folders e.g.
!/Music/NewMusic & ~/Music/OldMusic and I moved the files from ~/Music into those 2 new folders, accordingly. After I restarted Gnome-Music, the crash happened. What I noticed, even in Gnome 3.12 & 3.14 ( not in Gnome 3.10 tough)
if I add / move audio files from - into ~/Music, then Gnome-Music either crashes or behaves bad, like not recognising all the audio files inside the Music folder, even if they are there. This is untill I log out and back in the session. After that, Gnome-Music works fine.
Comment 14 David King 2014-10-08 19:50:21 UTC 
This is a bug report about EasyTAG crashing, not GNOME Music. EasyTAG does not use GNOME Music, so I do not think that the crash could be related. Do you have any idea about how to reproduce the EasyTAG crash? It seems that a CDDB search was being run, but are there any other details, like if there are a series of steps that can reliably reproduce the crash?
Comment 15 Bogdan Mințoi 2014-10-08 19:55:51 UTC 
(In reply to David King from comment #14)
> This is a bug report about EasyTAG crashing, not GNOME Music. EasyTAG does
> not use GNOME Music, so I do not think that the crash could be related. Do
> you have any idea about how to reproduce the EasyTAG crash? It seems that a
> CDDB search was being run, but are there any other details, like if there
> are a series of steps that can reliably reproduce the crash?

I'm sorry, that was for another bug I submitted, regarding Gnome-Music, my mistake. 
About EasyTag, the crash happened while I was searching trough CDDB - the application just hangs and eventually I had to terminate the process since it doesn't respond to any command.
Comment 16 David King 2014-10-08 20:27:27 UTC 
In that case, there is an upstream bug about this. It needs a lot of rewriting, so is unlikely to be fixed soon.