GNOME Bugzilla – Bug 648839
Closing Metadata Fixer can cause segfault; TreeStore.gtk_tree_model_get_value null
Last modified: 2020-03-17 09:19:17 UTC
Created attachment 186796 [details] debug log of crash Running Banshee 2.0. Also tested on git master. Steps to reproduce: 1) Open Metadata Fixer 2) In Sources pane, right click Metadata Fixer and select Close 3) Left-click on a menu such as View and scroll the mouse laterally across a few of the other menus (across Edit and File, then back to the right) 4) After moving over only a couple menus, Banshee will crash. There is no risk of crash if you left-click on another item in the Sources pane before clicking on one of the menus (between steps 2 and 3).
I just noticed the crash always happens over the Edit menu, but only if you click on another menu first. If you click on Edit first, it won't crash unless you try to open the Metadata Fixer again.
Created attachment 187163 [details] [review] Corrects an error where an out-of-date variable was causing an attempt to reference non-existent TreeView item It looks like highlight_iter is supposed to represent the TreeIter of the currently selected item in SourceView. Unfortunately, it wasn't always updating when the selection changed (such as when Metadata Fixer was being closed). Given that Selection already represents the TreeSelection for SourceView, I replaced any references to highlight_iter with public methods of Selection to fix the problem.
Review of attachment 187163 [details] [review]: Have you tested this patch? I would think that calling SelectIter would activate that source, which would make Banshee switch to it - where the point of the HighlightSource is that you can right-click it without switching to it.
I tested it, though I suppose I didn't do a thorough comparison between existing functionality and patched functionality. SelectIter will change the selection, but it does not change the active source. With this patch, a right-click will cause the right-clicked item to be highlighted and a pop-up menu will open for the item. After closing the right-click menu (by clicking outside the menu), the selection will disappear (nothing will be selected). Throughout all this, the active source remains the same. Side note: As a side effect, renaming a playlist will not cause the source to switch to the playlist with this patch. Without the patch, renaming causes a source change. (I kind of like this side effect) As banshee is now, a right-click will not move the selection. When the pop-up menu is draw, the item that was right-clicked is only outlined. So the selection actually stays the same through the whole pop-up menu process. Would it be acceptable to have the selection change when a right-click happens, then revert the selection back to the active source when the pop-up menu is closed? If so, that could be done with a minor change to my patch. Or would it be preferable to keep the UI as it is, where the selection doesn't change at all on a right-click and the item right-click simply gets an outline?
Created attachment 187548 [details] [review] An alternate fix that simply ensures highlight_iter is updated when the active source is changed. This is a less dramatic approach that also fixes the problem. ResetSelection gets called when on an ActiveSourceChanged event. As a result, Selection is changed, but highlight_iter isn't. I added a line to update highlight_iter as well. This way, highlight_iter can still differ from Selection when an item is right-clicked, but they agree in all other cases.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.