Description of problem: Attempted to “Reload Tree” after some directories had been removed. Not obvious how to reproduce the problem. Version-Release number of selected component: easytag-2.2.3-1.fc20 Additional info: reporter: libreport-2.2.2 backtrace_rating: 4 cmdline: easytag crash_function: gtk_tree_store_get_path executable: /usr/bin/easytag kernel: 3.15.3-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 gtk_tree_store_get_path at gtktreestore.c:592 #2 gtk_tree_store_remove at gtktreestore.c:1227 #3 gtk_tree_store_clear_traverse at gtktreestore.c:1856 #10 gtk_tree_store_clear at gtktreestore.c:1884 #11 Browser_Tree_Initialize at src/browser.c:2513 #12 Browser_Tree_Rebuild at src/browser.c:2642 #17 _gtk_action_emit_activate at deprecated/gtkaction.c:906 #22 gtk_widget_activate at gtkwidget.c:7199 #23 gtk_menu_shell_activate_item at gtkmenushell.c:1391 #24 gtk_menu_shell_button_release at gtkmenushell.c:805
Created attachment 919074 [details] File: backtrace
Created attachment 919075 [details] File: cgroup
Created attachment 919076 [details] File: core_backtrace
Created attachment 919077 [details] File: dso_list
Created attachment 919078 [details] File: environ
Created attachment 919079 [details] File: exploitable
Created attachment 919080 [details] File: limits
Created attachment 919081 [details] File: maps
Created attachment 919082 [details] File: open_fds
Created attachment 919083 [details] File: proc_pid_status
Created attachment 919084 [details] File: var_log_messages
This is probably because the browser tree is cleared (as part of the "reload tree" process) and the selection changes, which then triggers reading of the removed rows from the model. I can't reproduce a crash, but I can reproduce some odd behaviour when removing the directory for a selected row during runtime, and then calling "reload tree". I just created a patch which fixes the behaviour for me, so please test the following scratch build and let me know if it works for you: http://koji.fedoraproject.org/koji/taskinfo?taskID=7162274
Hard to be sure of a “fix” since I had no technique for reproducing the original crash, but I’ll use this for a few days in a similar workflow and report whether the reload tree seems stable and well behaved. Thanks!
Thanks! Just to be clear, by steps to reproduce (given that I could only reproduce a constant reloading of the directory tree, not a crash) were: 1. mkdir foo 2. launch EasyTAG 3. select foo in the directory list 4. rmdir foo 5. reload tree If the crash turns out to be something different, which it might be, steps to reproduce would be fantastic.
I also encountered the constant reloading loop you mentioned. The scratch build you posted seems to have fixed that, and testing so far has not produced any segfaults either. I think this is probably fixed. Thanks!
Thanks for the confirmation. I pushed the patch upstream, and it will be in the next stable update for the easytag package, together with the eventual fix for bug 1121142. https://git.gnome.org/browse/easytag/commit/?id=ef9c43474c36c7660e67420bba514559bf7163a3
easytag-2.2.4-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/easytag-2.2.4-1.fc21
easytag-2.2.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/easytag-2.2.4-1.fc20
easytag-2.2.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/easytag-2.2.4-1.fc19
easytag-2.2.4-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/easytag-2.2.4-1.el7
Package easytag-2.2.4-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing easytag-2.2.4-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11767/easytag-2.2.4-1.fc20 then log in and leave karma (feedback).
easytag-2.2.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
easytag-2.2.4-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.4-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
easytag-2.2.4-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.