Description of problem: I drag/dropped a jpeg file from an nfs share onto the image tab. I have drag/dropped several before and this is the first time it crashed. Ernie D Version-Release number of selected component: easytag-2.2.0-1.fc20 Additional info: reporter: libreport-2.2.1 backtrace_rating: 4 cmdline: easytag crash_function: g_realloc executable: /usr/bin/easytag kernel: 3.13.10-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #7 g_realloc at gmem.c:169 #8 g_array_maybe_expand at garray.c:785 #9 g_array_insert_vals at garray.c:526 #10 _gtk_style_context_peek_style_property at gtkstylecontext.c:2321 #11 gtk_widget_style_get_valist at gtkwidget.c:12522 #12 gtk_widget_style_get at gtkwidget.c:12560 #13 gtk_tree_view_get_expander_size at gtktreeview.c:2925 #14 gtk_tree_view_get_row_height at gtktreeview.c:13632 #15 _gtk_tree_view_queue_draw_node at gtktreeview.c:9995 #16 gtk_tree_selection_real_select_node at gtktreeselection.c:1641 Potential duplicate: bug 958626
Created attachment 890989 [details] File: backtrace
Created attachment 890990 [details] File: cgroup
Created attachment 890991 [details] File: core_backtrace
Created attachment 890992 [details] File: dso_list
Created attachment 890993 [details] File: environ
Created attachment 890994 [details] File: limits
Created attachment 890995 [details] File: maps
Created attachment 890996 [details] File: open_fds
Created attachment 890997 [details] File: proc_pid_status
Created attachment 890998 [details] File: var_log_messages
Hi, thanks for the bug report. This sounds like it might be bug 1088022, so could you test the 2.2.1-1 update which is currently working through updates-testing, and let me know if it works? https://admin.fedoraproject.org/updates/FEDORA-2014-5539/easytag-2.2.1-1.fc20 If not, the cover art support has now been reworked (and fixed, from what I can tell from my testing) upstream, so a future 2.2.2 upstream release, which is due in the next week or two, should be something to try, so I can push out a test build of that.
(In reply to David King from comment #11) > Hi, thanks for the bug report. This sounds like it might be bug 1088022, so > could you test the 2.2.1-1 update which is currently working through > updates-testing, and let me know if it works? > > https://admin.fedoraproject.org/updates/FEDORA-2014-5539/easytag-2.2.1-1.fc20 > > If not, the cover art support has now been reworked (and fixed, from what I > can tell from my testing) upstream, so a future 2.2.2 upstream release, > which is due in the next week or two, should be something to try, so I can > push out a test build of that. The thing is, It doesn't seem to be repeatable. When I tried it again, It was sucessful: I noticed that the image in question was rather large, 1+MB. I still have a large number of images to import. I will continue to drag/drop and if the problem repeats itself, I will switch to the 2.2.1-1 update and retry. Otherwise, and unless you would like some extended "beta" testing on 2.2.1-1, I will continue with the currrent version. Ernie D
The reproducibility (or lack thereof) is probably because 2.2.0 contained a rework of the image loading/saving which used asynchronous operations (and threads internally). This has been reverted for 2.2.2, so should fix all (known) problems with covert art handling. I will close this as upstream for now, and if 2.2.2 does not fix the problem once and for all please reopen.
*** Bug 1088022 has been marked as a duplicate of this bug. ***
easytag-2.2.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/easytag-2.2.2-1.fc20
easytag-2.2.2-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/easytag-2.2.2-1.fc19
easytag-2.2.2-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
easytag-2.2.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.