GNOME Bugzilla – Bug 386180
Reference counting errors with shared ActionGroups among Windows
Last modified: 2007-06-12 16:19:53 UTC
When implementing an SDI, I encountered problems when I shared an ActionGroup among several Windows (representing the documents). The same functionality implemented without ActionGroups, but with buttons and simple callbacks, doesn't produce the same errors. Both versions are attatched below.
Created attachment 78425 [details] The gtk-error producing example Compile and run. Then create a new image, close the first one (the one with #1), and observe gtk-errors.
Created attachment 78426 [details] The working non-ActionGroup example. Compile and run. No errors!
Comment on attachment 78425 [details] The gtk-error producing example Compile and run. Then create a new image, close the first one (the one with #1), and observe gtk-errors.
To avoid confusion: The update of the first example involves only chaning mimetype from text/plain to text/x-c++src. I didn't realize it would create a new 'post'. So, you don't need to look for modifications of the patch itself.
Created attachment 82285 [details] simplified_test.cc Here is a simplified test case. It seems to be some problem with GtkAccelGroup in GTK+. It might be caused by how we use these objects from gtkmm, but I'd like to see a GTK+ test case to confirm that. This test produces this output, without the need for any UI interaction: murrayc@ubuntumurrayc:~$ g++ test.cc `pkg-config gtkmm-2.4 --libs --cflags` murrayc@ubuntumurrayc:~$ ./a.out debug: before delete window (a.out:20034): Gtk-CRITICAL **: _gtk_accel_map_remove_group: assertion `entry != NULL' failed (a.out:20034): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `<invalid>' (a.out:20034): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (a.out:20034): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `<invalid>' (a.out:20034): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed debug: after delete window When breaking on g_log, we see this backtrace at the first glib warning: Breakpoint 2, IA__g_log (log_domain=0xb7b584a1 "Gtk", log_level=G_LOG_LEVEL_CRITICAL, format=0xb765ffbb "%s: assertion `%s' failed") at gmessages.c:516 516 va_start (args, format); (gdb) bt
+ Trace 109562
Actually, it looks like the GtkAccelGroup is being destroyed (finalized) too early - it should stay alive while it is used by the other GtkUIManager. gtk_ui_manager_insert_action_group() does seem to g_object_ref() it properly. A GTK+ test case does seem to be necessary.
The same functionality implemented with Ruby/GNOME2 also gives similar problems, so this is likely to be a GTK+ problem.
Created attachment 86348 [details] GTK+ testcase This is a GTK+ testcase for the problem. I think there are actually two problems: The first message (gtk-testcase:4854): Gtk-CRITICAL **: _gtk_accel_map_remove_group: assertion `entry != NULL' failed is caused by a rather simple GTK+ bug (#429732). The others are because the UI manager is destroyed before the window is destroyed (try changing the order in destroy_window() in that GTK+ testcase to see them disappear). I have another GTK+ patch for this ready that does additional reference counting of the AccelGroup in GtkAccelLabel, but I am not sure whether it is actually a GTK+ problem. Since the window makes use of the UI manager (and not the other way around), it seems correct that first the window has to be deleted, and then the UI manager. In the C++ case, the UI manager is deleted before the window because the MyWindow destructor deletes the UI manager before the inherited destructor actually deletes the rest of the window.
Well done. I have CCed myself to your first GTK+ bug. > Since the window makes use of the UI manager (and not the other way > around), it seems correct that first the window has to be deleted, and then the > UI manager In general, I don't think GTK+ enforces this kind of sequence. Please submit your GTK+ patch, with your test case, and we will see. If that is rejected, or if there is no response, we might think about a gtkmm workaround.
I filed another GTK+ bug (#429970) with that patch attached.
According to bug #429970, this should not be allowed. Martin, do you think that you could instead achieve this by using one UIManager and one UI description, containing menu and toolbar descriptions that use the same action names?
Yes that would probably work, and if not some other way will. (I currently don't have the time to dig into this problem) I think the main point is that there should be a warning (as you've already pointed out in bug #429970) when one tries to do what I tried to do. I will close this as NOTABUG and pass on the problem to bug #429970.