I have the same problem and all I could get from gdb was that it's in glib somewhere.

does it go away after downgrading to 9.0.31.0?

coolo: how do you reproduce the hang? it works fine here. 

Opening a Flash heavy site in Konqueror triggers the hang on my machine.

http://www.eurogamer.net

thanks, not reproduceable here. 

Going back to flash 9.0.31 from Alpha5 does not fix it.

BTW, Firefox does not have any problem with flash sites.

So it does not appear to be caused by the flash plugin itself.

I can reproduce this with http://www.vgn.de ...

Downgrade of flash-player to 9.0.31 didn't helped here either...

dani@g205:~> rpm -q kdebase3-nsplugin flash-player
flash-player-9.0.48.0-4
kdebase3-nsplugin-3.5.7-34

Rudi had the same. I wonder you can't see it

backtrace:

warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4

IA__g_slist_find (list=0x80e3d00, data=0xf5a0598c) at gslist.c:378
378     }
(gdb) bt
#0  IA__g_slist_find (list=0x80e3d00, data=0xf5a0598c) at gslist.c:378
#1  0xf5a72943 in IA__g_once_init_enter_impl (value_location=0xf5a0598c) at gthread.c:214
#2  0xf598ee4f in IA__gdk_display_get_type () at /usr/include/glib-2.0/glib/gthread.h:338
#3  0xf59afffe in _gdk_display_x11_get_type () at gdkdisplay-x11.c:108
#4  0xf59b11fb in IA__gdk_display_open (display_name=0x0) at gdkdisplay-x11.c:157
#5  0xf598da0d in IA__gdk_display_open_default_libgtk_only () at gdk.c:288
#6  0xf5c7d02f in IA__gtk_init_check (argc=0x0, argv=0x0) at gtkmain.c:898
#7  0xf5c7d064 in IA__gtk_init (argc=0x0, argv=0x0) at gtkmain.c:933
#8  0xf5f30a35 in ?? () from /usr/lib/browser-plugins/libflashplayer.so
#9  0xf5f2b629 in ?? () from /usr/lib/browser-plugins/libflashplayer.so
#10 0xf5f2d4e4 in ?? () from /usr/lib/browser-plugins/libflashplayer.so
#11 0xfff8d388 in ?? ()
#12 0x080d78c8 in ?? ()
#13 0x00000001 in ?? ()
#14 0x0000000a in ?? ()
#15 0x080d9080 in ?? ()
#16 0x080d90b0 in ?? ()
#17 0x00000000 in ?? ()

this is what I get on stdout from konqueror:

Flash Player: Warning: environment variable G_FILENAME_ENCODING is set and is not UTF-8

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

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

(process:19191): 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);

Federico, is there anything we can do? This seems to be a major regression

How weird.  The first warning ("initialization assertion failed...") happens if you don't call g_type_init(), but the stack trace shows that gtk_init() is being called --- which should be enough.

Can you please load the program under gdb, set a breakpoint in g_log(), and get a stack trace where the first warning happens?

I have also seen this since on x86_64 on Alpha6 and all subsequent factory updates.

rpm -q --qf '%{n}-%{v}-%{r}.%{arch}\n' kdebase3 kdelibs3 kdebase3-nsplugin nspluginwrapper flash-player
kdebase3-3.5.7-37.x86_64
kdelibs3-3.5.7-36.x86_64
kdebase3-nsplugin-3.5.7-37.i586
nspluginwrapper-0.9.91.4-36.x86_64
flash-player-9.0.48.0-6.i586


Is the arch for nspluginwrapper correct?

do you guys have gtk2 2.11.6 installed? it works fine with gtk2 2.11.5 (alpha6, like the bugreport says). 

I guess this bugreport is post alpha6 then, right?

*** Bug 296887 has been marked as a duplicate of this bug. ***

Marcus: does it work for you when going back to gtk2 2.11.5 as well?

Yes, works fine when I use gtk2 2.11.5.

Thanks. Federico, could you look into the diff and see if there is a obvious bug?

21:14 < coolo> federico1: ping
21:15 < coolo> 214           while (g_slist_find (g_once_init_list, (void*) value_location))
21:15 < coolo> 215             g_cond_wait (g_once_cond, g_once_mutex);
21:15 < coolo> that loop is never exited
21:16 < coolo> IA__g_once_init_enter_impl (value_location=0xb5a8c98c) at gthread.c:214
21:18 < coolo> (gdb) print g_once_init_list->next->data
21:18 < coolo> $17 = (gpointer) 0xb5a8c98c
21:18 < coolo> so it's in the list and always returned
21:18 < coolo> and both g_once_cond and g_once_mutex are 0x0

Coolo says that visiting youtube.com in konqueror is enough to trigger this.

I'd try to help with #12 but don't really know how.
I can only attach to gdb if the process is stuck already,
tried a wrapper around nspluginviewer, but that does not work.

how to attach to gdb early enough (before the log messages) ?

played around a bit since I suspected it could as well be glib2 as well
as gtk2, but it's really gtk2.

glib2-32bit-2.13.5-3.x86_64.rpm,gtk2-32bit-2.11.5-3.x86_64.rpm works
(as on Alpha6)

glib2-32bit-2.13.7-5.x86_64.rpm,gtk2-32bit-2.11.5-3.x86_64.rpm works
(Alpha7 glib2, Alpha6 gtk2)

glib2-32bit-2.13.5-3.x86_64.rpm,gtk2-32bit-2.11.6-4.x86_64.rpm 
 (no flash, would probably need recompile of gtk with older glib)

glib2-32bit-2.13.7-5.x86_64.rpm,gtk2-32bit-2.11.6-4.x86_64.rpm hangs
(Alpha7 glib2, Alpha7 gtk2) this is the hang this bug is about.

the backtrace is:

#0  IA__g_log (log_domain=0xb5ac74fb "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL,
    format=0xb5acbd1c "%s: initialization assertion failed, use %s() prior to this function")
    at gmessages.c:516
#1  0xb5abd7de in IA__g_type_register_static (parent_type=80, type_name=0xb59b43f6 "GdkDisplay",
    info=0xbfba7b04, flags=0) at gtype.c:2242
#2  0xb5abdc99 in IA__g_type_register_static_simple (parent_type=80,
    type_name=0xb59b43f6 "GdkDisplay", class_size=88,
    class_init=0xb59623d0 <gdk_display_class_intern_init>, instance_size=80,
    instance_init=0xb5962580 <gdk_display_init>, flags=0) at gtype.c:2230
#3  0xb5961e9d in IA__gdk_display_get_type () at gdkdisplay.c:87
#4  0xb5d95e55 in IA__gtk_clipboard_get_for_display (display=0x0, selection=0x1)
    at gtkclipboard.c:290
#5  0xb5d95ef6 in IA__gtk_clipboard_get (selection=0x1) at gtkclipboard.c:315
#6  0xb5ee79ec in ?? () from /usr/lib/browser-plugins/libflashplayer.so

wow, looks like the real change is caused by the glib2 update ...


I've got here a gtk2-32bit-2.11.6 installed that was built with
glib2-2.13.5 (using a rebuilt pango built with that same glib2).

running a combination between this gtk2-32bit-2.11.6 and the
current glib2 (glib2-32bit-2.13.7) I've got a working flashplayer.

So it looks like the new glib2 offers some features to gtk2
that cause the hang when really used.

for #22, the missing symbol in case3 (old glib2, new gtk2)
was libgdk-111-2.0.so.0: undefined symbol: g_once_init_enter_impl
which is interestingly in the backtrace mentioned above ...

g_once_init_enter_impl is also touched in bug 297636. does it work with that glib2?

*** Bug 297519 has been marked as a duplicate of this bug. ***

Opera is also affected, I hear.

For reference, the upstream bug which introduced the patch in glib is http://bugzilla.gnome.org/show_bug.cgi?id=65041

(10:55:19 AM) mclasen: federico: are you compiling with -O3 ?
(10:55:55 AM) mclasen: it seems that gcc has started to move our const-annotated get_type functions wildly around

in case that was a question: no, we build with -O2. but I don't really get it, because if you annotate a function as const then that means that the compiler is allowed to move it out of hot code spots. if something breaks then thats not really a compiler issue. 

glib2 has some bugfixes in this area in STABLE already (from andreas schwab)

perhaps they help.

You're seeing ghosts? The only change from andreas is for #297636

I just wanted to confirm that I have this problem too in A7. It seems that any flash sites at all will cause it to hang.

I also have the problem in the latest Kubuntu release, so it is not Suse specific. 

beta1 has it as well

Received this from timj:
  hi, i have found and fixed a race in g_once_init, and thus
  closed http://bugzilla.gnome.org/show_bug.cgi?id=65041.
  so please try again with recent SVN.

I don't think we can release 10.3 with this issue

as dirk says, timj's race fix did not help.

any news on this?

This problem is not solved in beta 2

it's very strange bug - I have opensuse 10.2 with most unofficial repos and updated frequently and I don't have this bug. But in SUse 10.1 I have this bug and can't get rid of it

don't hijack bugreports. this is solely about a 10.3 regression. for 10.1 file a new bugreport. 

Flash is completely broken in Opera 9.23 on 10.3 beta 2. Everytime I try to access any flash based content (including the flash version check at http://www.adobe.com/shockwave/welcome/) I get 100% cpu usage by operapluginwrapper for about 5 seconds and then it terminates (opera is still running).

Rename reflecting broader impact of bug

A mandriva guy has a hack that works around this problem for kde:

http://people.mandriva.com/~boiko/patches/kdebase-3.5.7-fix_flashplayer_nsplugin.patch

I finally got a KDE session set up on 10.3.  When I visit youtube with Konqueror, youtube tells me that I don't have Javascript enabled, or that I have an old version of Flash player.

Tools/HTML Settings/Javascript is turned on, and Firefox of course works fine.  How do I make Youtube work in Konqueror?

I can confirm that the patch I linked above fixes the problem in konqueror on my machine.

I built a test package in the build service

http://download.opensuse.org/repositories/home:/benjimanw/openSUSE_Factory/i586/kdebase3-nsplugin-3.5.7-94.1.i586.rpm

#45: youtube doesn't test separately for broken JS and broken Flash, so you need to test separately on other sites which is really causing you the problem.

Assuming it's Flash, go to Configure Konqueror->Plugins and check that "Enabled plugins globally" in Global Settings is checked, and click the "Scan for plugins" button, then check that libflashplayer is found on the Plugins tab.

*** Bug 305230 has been marked as a duplicate of this bug. ***

I tested with the newest flashplayer beta and found that it is also affected by the bug, contrary to some anecdotal evidence on IRC.

(In reply to comment #47 from Will Stephenson)
> Assuming it's Flash, go to Configure Konqueror->Plugins and check that "Enabled
> plugins globally" in Global Settings is checked, and click the "Scan for
> plugins" button, then check that libflashplayer is found on the Plugins tab.

Huh... I go to the Settings / Configure Konqueror window, and there's no "Plugins" item.  I only get "Behavior", "Appearance", "Previews & Meta-Data", and "Performance".  How can I show the Plugins options?

How did you set your KDE session? Not via selecting the KDE pattern? Do you have the kdebase3-nsplugin package installed?

I guess Stephan meant to say "How did you install your KDE session".

Installing the "KDE Base System" pattern should be sufficient.  

I also see this behavior for flash/opera on 10.3 beta2 on i586, with the same reported messages to stdout the reudiger reported in comment #10:

  Flash Player: Warning: environment variable G_FILENAME_ENCODING is set and is not UTF-8

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

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

  (process:29689): 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);
  opera: Plug-in 29689 is not responding. It will be closed.
  opera: Define environment variable OPERA_KEEP_BLOCKED_PLUGIN to keep blocked plug-ins.

The odd thing is that I *also* saw this behavior for opera/flash within the past couple of days on up-to-date 10.2 before updating to 10.3 beta2 yesterday.

(In reply to comment #51 from Stephan Binner)
> How did you set your KDE session? Not via selecting the KDE pattern? Do you
> have the kdebase3-nsplugin package installed?

(In reply to comment #52 from Will Stephenson)
> I guess Stephan meant to say "How did you install your KDE session".
> 
> Installing the "KDE Base System" pattern should be sufficient.  

That's what I did when installing my box, I think.  I'll reinstall those packages.

libflashplayer.so is doing something really dumb.  It's calling GTK+ functions (gtk_clipboard_get(), in particular) before calling gtk_init().  This is the code it has:

(gdb) x/20i $pc-5
0xb5f499e7:     call   0xb5f3d828 <gtk_clipboard_get@plt>
0xb5f499ec:     test   %eax,%eax
0xb5f499ee:     jne    0xb5f49ab8
0xb5f499f4:     mov    -0x81c(%ebx),%eax
0xb5f499fa:     mov    $0x1,%ecx
0xb5f499ff:     mov    %eax,-0x10(%ebp)
0xb5f49a02:     mov    (%eax),%eax
0xb5f49a04:     mov    %ecx,0x4(%esp)
0xb5f49a08:     mov    %eax,0xc(%esp)
0xb5f49a0c:     mov    $0x63,%eax
0xb5f49a11:     mov    %eax,0x8(%esp)
0xb5f49a15:     lea    -0xa4284(%ebx),%eax
0xb5f49a1b:     mov    %eax,(%esp)
0xb5f49a1e:     call   0xb5f3ddb8 <fwrite@plt>
0xb5f49a23:     xor    %edx,%edx
0xb5f49a25:     mov    %edx,0x4(%esp)
0xb5f49a29:     movl   $0x0,(%esp)
0xb5f49a30:     call   0xb5f3d4d8 <gtk_init@plt>

This reads roughly

  if (gtk_clipboard_get (GDK_SELECTION_PRIMARY) != NULL)
     goto 0xb5f49ab8;

  fwrite (...);

  gtk_init (...);

But gtk_clipboard_get() fails, as gtk_init() hasn't been called first.  This is a bug in libflashplayer.

I'll just include the patch mentioned in comment #44; it's a hack, but there's no way for us to fix libflashplayer for real.

> I'll just include the patch mentioned in comment #44; it's a hack, but there's
> no way for us to fix libflashplayer for real.
> 

Presumably this won't fix opera though. Why does the problem only occur with new glib/gtk?

> But gtk_clipboard_get() fails, as gtk_init() hasn't been called first.  This > is a bug in libflashplayer.

Why do you think so?

What the code's intention is that it tries to figure out if gtk_init() has been called already. There are two uses: 

a) in gtk+ based firefox, where gtk_init() has already been called

and 

b) in konqueror, which is not gtk+ based and therefore doesn't initialize gtk. 

the code above tries to figure out if it needs to call gtk_init(). it does that by calling a function that only works if gtk_init() was already called before, and if that one fails, it calls gtk_init(). 

the debug message "Adobe FlashPlayer: gtk_clipboard_get(GDK_SELECTION_PRIMARY); failed. Trying to call gtk_init(0,0);" is saying that, and Mike Melanson from Adobe Flash Player team has confirmed the intention of this code. 

However, given that it has been always that way with any version of gtk, why is it suddenly a bug in flash player that glib2 produces an endless loop?

The real question was already in comment #19, and it is still unanswered: 

21:15 < coolo> 215             g_cond_wait (g_once_cond, g_once_mutex);
21:15 < coolo> that loop is never exited
21:16 < coolo> IA__g_once_init_enter_impl (value_location=0xb5a8c98c) at
gthread.c:214
21:18 < coolo> (gdb) print g_once_init_list->next->data
21:18 < coolo> $17 = (gpointer) 0xb5a8c98c

I feel so dirty now, but I sat down and wrote a two liner testcase: 

/*
   gcc `pkg-config --cflags gtk+-2.0` -o looptest looptest.c `pkg-config --libs gtk+-2.0`
*/

#include <gtk/gtkmain.h>

int main()
{
    if (!gtk_clipboard_get(GDK_SELECTION_PRIMARY))
        gtk_init(0,0);
}


this works fine with any version of gtk <= alpha6, and busyloops endlessly with gtk > alpha6. no flash player involved.

gah, wasted time. its already fixed upstream: 

http://bugzilla.gnome.org/show_bug.cgi?id=463773#c10 

Is it possible to backport this fix to glib 2.13?

*** Bug 306414 has been marked as a duplicate of this bug. ***

(In reply to comment #57 from Dirk Mueller)
> What the code's intention is that it tries to figure out if gtk_init() has been
> called already.

Ah, but no app should need to do this.  gtk_init() and friends are idempotent; calls subsequent to the first one are no-ops.

Flash player should simply call gtk_init() unconditionally.  Since we cannot fix it, we can simply use the patch to call gtk_init() from nspluginviewer always.

> the code above tries to figure out if it needs to call gtk_init(). it does that
> by calling a function that only works if gtk_init() was already called before,
> and if that one fails, it calls gtk_init(). 

This is the wrong way to do things on several levels:

- No code needs to know if GTK+ is initialized, as it can always call gtk_init() with no ill results.

- Calling any GTK+ functions before gtk_init() is called is *documented* to be wrong.  With an older glib, this will almost certainly print a warning (or it would crash if your glib was compiled with --disable-debug, or it would crash if you were running a development version of GNOME, since those make critical warnings crash automatically to catch bugs sooner - see http://mail.gnome.org/archives/desktop-devel-list/2005-November/msg00051.html about this).

- This is like watching for EBADFD to say, "oh, I guess I should have opened the file first" :)

Added a patch to fix it like discussed in the upstream bug report. Verified that it fixes the problem with both Opera and Konqueror and that a GNOME desktop still works.

Thanks. I would like to give it a try. Which package do I need to update? mbuilding it is fine for me.

Thanks. Updating gtk2 works fine for me. :-)

(In reply to comment #66 from Stefan Dirsch)
> Thanks. Updating gtk2 works fine for me. :-)
> 

(In reply to comment #63 from Stephan Binner)
> Added a patch to fix it like discussed in the upstream bug report. Verified
> that it fixes the problem with both Opera and Konqueror and that a GNOME
> desktop still works.
> 

Hi,

what shall I do to fix the bug?
Where can I download the patch?

Could you tell me please step by step instructions?

Thank you.

I have submitted a patch for Online Update.

(In reply to comment #68 from Marcus Meissner)
> I have submitted a patch for Online Update.
> 

Please tell me where can I download it from!

Regards.

Thanks, Stephan and Marcus :)

> Hi,
> 
> what shall I do to fix the bug?
> Where can I download the patch?
> 
> Could you tell me please step by step instructions?
> 
> Thank you.
> 

The current factory contains fixed packages (version 2.11.6-19), note that you also have to update gtk2-32bit package if you are using x86_64.

And yes, don't tell anyone, looks like this is a top-secret ;)

VERIFIED in beta3 - thanks for fixing!