GNOME Bugzilla – Bug 702546
Crash in in nautilus_trash_bar_dispose at nautilus-trash-bar.c:109
Last modified: 2013-06-25 17:09:01 UTC
Created attachment 247127 [details] stacktrace of this crash Reproduced with glib >= 2.37.1. Originally reported on Ubuntu but I just checked on current fc20. 1. Open nautilus 2. Click wastebasket/trash. 3. Close the window Nautilus segfaults at this point. Trace attached (it's one reported by an Ubuntu user and retraced by launchpad).
Sorry, should have said that the trace is from 3.6.3 in current saucy but I reproduced using 3.8.2 on fedora.
Created attachment 247246 [details] [review] trash-bar: Take a weak ref to the view for signal disconnection We were attempting to disconnect the signals from the NautilusView after it was already destroyed. Add a weak reference so we get our callback called at the right moment to do the destruction. Also switch to using g_signal_handlers_disconnect_by_func for robustness.
Perhaps something like this?
Review of attachment 247246 [details] [review]: ::: src/nautilus-trash-bar.c @@ -73,3 @@ - bar->priv->selection_handler_id = - g_signal_connect (bar->priv->view, "selection-changed", - G_CALLBACK (selection_changed_cb), bar); I believe the root of the issue here is that from nautilus-window-slot.c:location_has_really_changed() we call nautilus_window_slot_switch_new_content_view(), which will destroy the NautilusView, and then after that nautilus_window_slot_update_for_new_location(), which will ultimately call the dispose() in NautilusTrashBar - at that point, NautilusView has already just been destroyed. It looks to me we should be able to destroy the extra location widgets from nautilus_window_slot_switch_new_content_view() before destroying the view instead, and avoid this problem altogether.
(In reply to comment #4) > I believe the root of the issue here is that from > nautilus-window-slot.c:location_has_really_changed() we call > nautilus_window_slot_switch_new_content_view(), which will destroy the > NautilusView, and then after that > nautilus_window_slot_update_for_new_location(), which will ultimately call the > dispose() in NautilusTrashBar - at that point, NautilusView has already just > been destroyed. > > It looks to me we should be able to destroy the extra location widgets from > nautilus_window_slot_switch_new_content_view() before destroying the view > instead, and avoid this problem altogether. Cheers. This led me to a better solution. I don't think that we need to add that into nautilus_window_slot_switch_new_content_view() - this is called from location_has_really_changed() which calls nautilus_window_slot_update_for_new_location() and this function does remove the extra location widgets. Where they aren't removed though is when disposing NautilusWindowSlot, which also unrefs the NautilusView. Doing the same there fixes it for me. WDYT?
Created attachment 247308 [details] [review] Remove extra location widgets when disposing NautilusWindowSlot This causes the widgets to be properly destroyed before the NautilusView is.
Review of attachment 247308 [details] [review]: Thanks, this looks good.
please commit (also to 3-8)
Pushed now. Attachment 247308 [details] pushed as 5c00b42 - Remove extra location widgets when disposing NautilusWindowSlot