GNOME Bugzilla – Bug 550250
nautilus crashed with SIGSEGV in g_type_check_instance_cast()
Last modified: 2009-03-12 14:18:08 UTC
the bug has been opened on https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/263246 "This happens when I I tried to add a new program to the run menu that pops up when inserting DVD media. nautilus 1:2.23.90-0ubuntu1
+ Trace 206008
I'm not quite sure precisely what went wrong here, but here's an educated guess: nautilus_autorun_prepare_combo_box is being called from nautilus_autorun_rebuild_combo_box, which then proceeds to overwrite the existing data attached to the combo box (from an earlier nautilus_autorun_prepare_combo_box, say the init one in do_autorun_for_content_type) and so then the callback we're seeing fail here is the one attached to the *earlier* copy of a NautilusAutorunComboBoxData. Possible thing that might fix this is calling g_object_get_data on the combo_box before the g_object_set_data_full call in nautilus_autorun_prepare_combo_box and destroying the old callback if there's an existing structure already kicking around. Looks like it's at least nominally reproducible, so this is possibly worth doing if one of the reporters is willing to test a random patch.
*** Bug 572781 has been marked as a duplicate of this bug. ***
valgrind says this when adding a new program for DVD handling: ==11051== ==11051== Invalid read of size 4 ==11051== at 0x49EE10: dialog_destroy_cb (nautilus-autorun.c:246) ==11051== by 0x7C3571C: g_closure_invoke (gclosure.c:767) ==11051== by 0x7C4C56A: signal_emit_unlocked_R (gsignal.c:3244) ==11051== by 0x7C4DBE6: g_signal_emit_valist (gsignal.c:2977) ==11051== by 0x7C4E0F2: g_signal_emit (gsignal.c:3034) ==11051== by 0x57F5D3D: gtk_object_dispose (gtkobject.c:421) ==11051== by 0x7C37C1F: g_object_run_dispose (gobject.c:789) ==11051== by 0x4F2AF8: response_cb (nautilus-open-with-dialog.c:329) ==11051== by 0x7C3571C: g_closure_invoke (gclosure.c:767) ==11051== by 0x7C4C56A: signal_emit_unlocked_R (gsignal.c:3244) ==11051== by 0x7C4DBE6: g_signal_emit_valist (gsignal.c:2977) ==11051== by 0x7C4E0F2: g_signal_emit (gsignal.c:3034) ==11051== Address 0x10bdc4f0 is 56 bytes inside a block of size 64 free'd ==11051== at 0x4A0609F: free (vg_replace_malloc.c:323) ==11051== by 0x7E91DF9: g_datalist_id_set_data_full (gdataset.c:282) ==11051== by 0x49EB64: nautilus_autorun_prepare_combo_box (nautilus-autorun.c:662) ==11051== by 0x49EDE7: nautilus_autorun_rebuild_combo_box (nautilus-autorun.c:376) ==11051== by 0x7C3571C: g_closure_invoke (gclosure.c:767) ==11051== by 0x7C4C56A: signal_emit_unlocked_R (gsignal.c:3244) ==11051== by 0x7C4DBE6: g_signal_emit_valist (gsignal.c:2977) ==11051== by 0x7C4E0F2: g_signal_emit (gsignal.c:3034) ==11051== by 0x4F2AD8: response_cb (nautilus-open-with-dialog.c:274) ==11051== by 0x7C3571C: g_closure_invoke (gclosure.c:767) ==11051== by 0x7C4C56A: signal_emit_unlocked_R (gsignal.c:3244) ==11051== by 0x7C4DBE6: g_signal_emit_valist (gsignal.c:2977)
nautilus-autorun.c: other_application_selected() does stuff, then sets data->other_application_selected and calls nautilus_autorun_rebuild_combo_box(). However, this recreates "data" freeing the original. Then we later get a dialog_destroy_cb() callback, which accesses the freed data...
Created attachment 130514 [details] [review] Don't re-allocate nautilus_autorun_combobox_data when rebuilding combo box
commited.