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:
runlevel: N 5
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]
Created attachment 919075 [details]
Created attachment 919076 [details]
Created attachment 919077 [details]
Created attachment 919078 [details]
Created attachment 919079 [details]
Created attachment 919080 [details]
Created attachment 919081 [details]
Created attachment 919082 [details]
Created attachment 919083 [details]
Created attachment 919084 [details]
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:
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.
easytag-2.2.4-1.fc21 has been submitted as an update for Fedora 21.
easytag-2.2.4-1.fc20 has been submitted as an update for Fedora 20.
easytag-2.2.4-1.fc19 has been submitted as an update for Fedora 19.
easytag-2.2.4-1.el7 has been submitted as an update for Fedora EPEL 7.
* 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:
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.