Checked flash when used from Konqueror, it gives the same assertions (one about that it needs to run g_type_init() before using any g_type function, one about that there's no GDK screen and another one which I don't remember).

This happens with both gtk 2.10.14 and gtk 2.10.6 when compiled against Glib 2.13 or Glib 2.14

if you see assertions such as "gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function", it's a GNUC_CONST/gcc issue, caused by gcc moving _get_type functions around to before gtk_init or g_type_init, bug #446565 has the proper fix for that (you failed to post the assertions you're seeing so this is just guess work).
if you really ran into a g_once_init_enter_impl race however, that should be fixed by:
Tue Aug 14 02:06:10 2007  Tim Janik  <timj@imendio.com>

        * glib/gthread.c (g_once_init_enter_impl): prevent race covered
        by g_once_init_enter(), by checking for previous initializations
        before entering initialisation branch.

        * tests/onceinit.c: added multi-thread/multi-initializer stress test
        using unoptimized g_once_init_enter_impl().

(In reply to comment #0)
> Since glib 2.13.x and 2.14.0, any gtk compiled against this version of glib
> locks up openoffice.org or flash when used from a KDE environment.
> 
> Reverting the commit in revision 5618 of glib/gobject/gtype.h and recompiling
> GTK makes it work again.
> 
> Some backtrace from OpenOffice at the moment it hangs:
> (gdb) bt
> #0  IA__g_slist_find (list=0x8185d00, data=0xb44e9e5c) at gslist.c:369
> #1  0xb42f9223 in IA__g_once_init_enter_impl (value_location=0xb44e9e5c)
>     at gthread.c:214

please try a recent glib freshly from SVN. if the problem still persists, please (re-)open a bug report with the following information:

- does the problem happen *every* time or infrequently?
- does it occour on multiple platforms (x86?) or is it platform specific?
- please send me (better yet: try to fix) ALL warnings/criticals
  that glib is producing before the problem occours.
- please send me the source file (or a link) which implements the
  particular g_once_init_enter() call in which you see the problem
  (might be called from a _get_type function or G_DEFINE_TYPE()).

[jan@laptop ~]$ OOO_FORCE_DESKTOP=kde soffice
libGL warning: 3D driver claims to not support visual 0x67

(process:27918): GLib-GObject-CRITICAL **: gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function

(process:27918): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(process:27918): Gdk-CRITICAL **: gdk_screen_get_font_options: assertion `GDK_IS_SCREEN (screen)' failed
<hangs here>

- happens every time OpenOffice is launched in KDE mode
- happens on AMD64 and i686
- assertions: see above
- source: see GTK source for gdk_screen_get_font_options, it checks if the screen is a screen type and calls get_type on the NULL screen. Due to the changed macro in the original bugreport, this goes into g_once_init_enter.

(In reply to comment #4)
> [jan@laptop ~]$ OOO_FORCE_DESKTOP=kde soffice
> libGL warning: 3D driver claims to not support visual 0x67
> 
> (process:27918): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
> assertion failed, use IA__g_type_init() prior to this function

the first assertion indicates that you're calling a _get_type function (or gdk_screen_get_font_options() respectively) prior to gtk_init.
after this assertion, *anything* can happen, the recent g_once_init_* changes just tend to make "anything" more fatal. simply fix getFontConfigHints() to call into gdk only after gtk (gdk) has been initialized.

Ok, so tell me to fix the flashplugin then, which has the same assertions. As a distribution maintainer, this is not acceptable. All these things worked fine with glib 2.12, but not with glib 2.14, so this is a regression. As a distribution, I have to revert the patch or keep things at gnome 2.18 to keep all things working.

(In reply to comment #6)
> Ok, so tell me to fix the flashplugin then, which has the same assertions. As a
> distribution maintainer, this is not acceptable. All these things worked fine
> with glib 2.12, but not with glib 2.14, so this is a regression. As a
> distribution, I have to revert the patch or keep things at gnome 2.18 to keep
> all things working.

unless reverting the patch would get rid of the assertions, there is no way this could be fixed in glib.

The assertions have always been there inside a non-GTK environment. With glib 2.12 and below, these programs have worked always. With GTK compiled with glib 2.14, they hangup your complete browser (Opera, Konqueror) or the application itself (OpenOffice).
Since this change has been introduced in glib 2.13.x, GTK does something completely different for gdk_screen_get_type when compiled against these new versions of glib.

It's either reverting this new behaviour, or changing the check in GTK (screen is always 0x0 in both flashplugin and Openoffice during these calls, so gdk_screen_get_type could check for NULL before actually executing the call).

This is the flashplugin in action in konqueror btw:

(process:869): GLib-GObject-CRITICAL **: gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function

(process:869): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(process:869): Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion `GDK_IS_DISPLAY (display)' failed
Adobe FlashPlayer: gtk_clipboard_get(GDK_SELECTION_PRIMARY); failed. Trying to call gtk_init(0,0);

For anyone who is looking for a solution to this problem:
I "fixed" the flashplugin case by adding an extra patch to GTK for now:

Flashplugin checks using gtk_clipboard_get(GDK_SELECTION_PRIMARY) to see if GTK is available, if not, it calls gtk_init to initialize this.

With the new glib 2.14 changes, the gtk_clipboard_get_for_display function checks for the display type, which is 0x0 in case of flashplugin. I added another check to this function, before GDK_IS_DISPLAY(display) is used to check for a valid display:

if (display == NULL) return NULL;

This fixes the flash crash, as it gets a NULL from that function without assertion, calls gtk_init and from that point all is fine again.

For OpenOffice, exporting two environment variables is enough to force GTK initialization. Fedora has a patch for this:
http://cvs.fedora.redhat.com/viewcvs/devel/openoffice.org/openoffice.org-1.9.88.rh133741.alwaysgtk.desktop.patch?rev=1.6&view=markup

Created attachment 94996 [details] [review]
workaround the issue

We use this patch in the Ubuntu GTK package, that makes the non-free flash work again

I guess we should probably release note this.

I guess we should probably release note this.

I've added a note to README.in. Please review.

(In reply to comment #14)
> I've added a note to README.in. Please review.

reviewed, thanks.

Dear Friends,

Okay, so for the non programmer who ends up at this bug via google,
how do I fix the mess?
libgtk 2.12.0-2(sebastian is listed as the maintainer, so I am presuming that running debian sid this should not be happening...)
glibc is 2.14.1-5


Best wishes,

Martin

I just committed the "g_return_if_fail (...)" patch to gtk+:

master - commit 4134c346f9e68367e515345c0ded07aa2b857a1a
gtk-2-16 - commit e2bce0d630c6f424664e81ee95352c4cbc41fc27

(In reply to comment #17)
> I just committed the "g_return_if_fail (...)" patch to gtk+:
> 
> master - commit 4134c346f9e68367e515345c0ded07aa2b857a1a
> gtk-2-16 - commit e2bce0d630c6f424664e81ee95352c4cbc41fc27

Federico, the patch is useless. It adds a display!=NULL check next to GDK_IS_DISPLAY(display). Like all other object types, the GDK_IS_DISPLAY() macro is implemented with G_TYPE_CHECK_INSTANCE_TYPE() which already checks for NULL instances.