GNOME Bugzilla – Bug 683923
gtk_application_add_window () unintentionally requires the application to be registered before adding a window to it
Last modified: 2012-09-17 09:07:21 UTC
On gtk+-3.5.5 my application works perfectly fine. On 3.5.17 I get the following and app. segfaults inside my call to gtk_application_add_window: (glchess:8032): GLib-GIO-CRITICAL **: g_application_list_actions: assertion `application->priv->is_registered' failed Program received signal SIGSEGV, Segmentation fault. 0x002fd0b0 in g_action_muxer_insert (muxer=0x8158d68, prefix=0x75d6b5 "app", action_group=0x80ee068) at gactionmuxer.c:645 645 for (i = 0; actions[i]; i++)
+ Trace 230843
This happens due to changes between gtk version 3.5.5 and 3.5.17 most likely due to many introductions in g_action_muxer_insert last month. I am opening this because you might see more application breaks like the above in near future.
We actually suffered this in the Epiphany test suite and ended up working it around there -- see 682653.
This change was intentional and it's already been around for a while (certainly long before the recent muxer changes). It does not make sense to create windows for non-primary-instance applications and you cannot possibly know that until after you have registered the app so any app that notices the difference probably has a bug in it already (and from what I recall with the Epiphany situation this was indeed the case).
Maybe you are right! I was just surprised that for 3.5.5 I didn't have to bother associating a window to MyApp instance only after run () has been called but just after gtk+ version increment, I needed to make sure I was making the associations only in activate()/open() or any later invocations of run() after performing registration. Epiphany also didn't need to call register() explicitly, I think. I guess no one does. It could have worked around just by making sure that it called gtk_application_add_window()/gtk_window_set_application() in any of the recommended functions called by run() after it does the implicit application registration. In my case I had to make decisions on which window to load depending on user supplied commandline so I would have had to take handling GOptionsContext out of main() (where it was traditionally done before calling run()) and split it across local_command_line() and command_line() vfuncs. Or in any case simplest for me was to not work on bleeding edge lower level libs like I accidently did by overtly depending on jhbuild to build the latest. In any case I understand maintaining gtk is a very responsible job you are handling so kudos for your attention on the issue!