Closed
Bug 718871
Opened 12 years ago
Closed 11 years ago
Native 64-bit flash player 11 plugin does not work anymore
Categories
(Firefox :: Untriaged, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: asolkar, Unassigned)
Details
Attachments
(1 file)
359.88 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120117 Firefox/12.0a1 Build ID: 20120117031056 Steps to reproduce: For many weeks now, I have been using 64-bit Firefox Nightly builds on 64-bit RHEL6.1. I had 64-bit Flash player 11.1.102.55 (http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_11_for_other_Linux_(.tar.gz)_64-bit). I placed libflashplayer.so from the package into .mozilla/plugins directory and it worked fine. Firefox Nightly auto-updates almost everyday. Actual results: Sometime last week, my flash player broke. Now when I load a web page that has flash content, it appears blank. If I switch to a different application and switch back, the flash area is all corrupt (see attached screenshot). Also as seen in the screenshot, some GTK-CRITICAL messages show up on console: ----- (<unknown>:4066): Gtk-CRITICAL **: gtk_widget_get_visual: assertion `GTK_IS_WIDGET (widget)' failed (<unknown>:4066): Gdk-CRITICAL **: gdk_colormap_new: assertion `GDK_IS_VISUAL (visual)' failed (<unknown>:4066): Gdk-CRITICAL **: gdk_colormap_alloc_colors: assertion `GDK_IS_COLORMAP (colormap)' failed (<unknown>:4066): Gtk-CRITICAL **: gtk_widget_modify_bg: assertion `GTK_IS_WIDGET (widget)' failed ----- Expected results: I ended up using nspluginwrapper to use 32-bit flash in 64-bit Firefox Nightly. This is not ideal. I would expect the native 64-bit flash player to work as beautifully as it was working few days ago.
Comment 1•12 years ago
|
||
I seem to be hitting the same issue - can confirm that the build from Jan 3 is OK, Jan 14 is busted. Also, plugin-container appears to be hung in a CPU-bound look spewing tons of stuff at the X server (both plugin-container and xorg end up at 100% CPU), stack traceback looks like: (gdb) where #0 0x00000034ae6e68f7 in __libc_writev (fd=<optimized out>, vector=<optimized out>, count=<optimized out>) at ../sysdeps/unix/sysv/linux/writev.c:56 #1 0x00007fa0479f2c83 in ?? () from /usr/lib64/libxcb.so.1 #2 0x00007fa0479f30ff in ?? () from /usr/lib64/libxcb.so.1 #3 0x00007fa0479f3184 in xcb_writev () from /usr/lib64/libxcb.so.1 #4 0x0000003e09c42e17 in _XSend (dpy=dpy@entry=0x7fa04777d000, data=data@entry=0x0, size=size@entry=0) at xcb_io.c:494 #5 0x0000003e09c431b0 in _XFlush (dpy=dpy@entry=0x7fa04777d000) at xcb_io.c:511 #6 0x0000003e09c2460a in XFlush (dpy=0x7fa04777d000) at Flush.c:39 #7 0x0000003e0d853c3d in IA__gdk_display_flush (display=<optimized out>) at gdkdisplay-x11.c:746 #8 0x0000003e0d842978 in flush_all_displays () at gdkwindow.c:5634 #9 IA__gdk_window_process_all_updates () at gdkwindow.c:5705 #10 0x0000003e0dcc0e31 in gtk_container_idle_sizer (data=<optimized out>) at gtkcontainer.c:1360 #11 0x0000003e0d81ea86 in gdk_threads_dispatch (data=0x7fa03c737ac0) at gdk.c:512 #12 0x00000034b064767a in g_main_dispatch (context=0x7fa047712d70) at gmain.c:2513 #13 g_main_context_dispatch (context=context@entry=0x7fa047712d70) at gmain.c:3050 #14 0x00000034b0647a40 in g_main_context_iterate (dispatch=1, block=<optimized out>, context= 0x7fa047712d70, self=<optimized out>) at gmain.c:3121 #15 g_main_context_iterate (context=0x7fa047712d70, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3058 #16 0x00000034b0647b07 in g_main_context_iteration (context=0x7fa047712d70, may_block=0) at gmain.c:3182 #17 0x00007fa04a11a5ae in ?? () from /usr/local/firefox/libxul.so #18 0x00007fa04a0f746e in ?? () from /usr/local/firefox/libxul.so #19 0x00007fa04957a53d in XRE_InitChildProcess () from /usr/local/firefox/libxul.so #20 0x00000000004013ed in _start () (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00000034ae6e5103 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 87 int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout); (gdb) where #0 0x00000034ae6e5103 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fa0479f2ba2 in ?? () from /usr/lib64/libxcb.so.1 #2 0x00007fa0479f416f in xcb_wait_for_reply () from /usr/lib64/libxcb.so.1 #3 0x0000003e09c433fd in _XReply (dpy=dpy@entry=0x7fa04777d000, rep=rep@entry=0x7ffff937da40, extra=extra@entry=0, discard=discard@entry=1) at xcb_io.c:601 #4 0x0000003e09c27dc9 in XGetGeometry (dpy=0x7fa04777d000, d=d@entry=94371882, root=root@entry= 0x7ffff937dad0, x=x@entry=0x7ffff937dad8, y=y@entry=0x7ffff937dadc, width=width@entry= 0x7ffff937dae0, height=height@entry=0x7ffff937dae4, borderWidth=borderWidth@entry= 0x7ffff937dae8, depth=depth@entry=0x7ffff937daec) at GetGeom.c:47 #5 0x0000003e0d874945 in gdk_window_x11_get_geometry (depth=0x0, height=0x7ffff937db8c, width= 0x7ffff937db88, y=0x7ffff937db84, x=0x7ffff937db80, window=0x7fa04778f5a0 [GdkWindow]) at gdkwindow-x11.c:2837 #6 gdk_window_x11_get_geometry (window=0x7fa04778f5a0 [GdkWindow], x=0x7ffff937db80, y= 0x7ffff937db84, width=0x7ffff937db88, height=0x7ffff937db8c, depth=0x0) at gdkwindow-x11.c:2820 #7 0x0000003e0d843f5c in IA__gdk_window_get_geometry (window=window@entry= 0x7fa04778f5a0 [GdkWindow], x=x@entry=0x7ffff937db80, y=y@entry=0x7ffff937db84, width=width@entry=0x7ffff937db88, height=height@entry=0x7ffff937db8c, depth=depth@entry=0x0) at gdkwindow.c:8275 #8 0x0000003e0d83c150 in IA__gdk_screen_get_monitor_at_window (screen= 0x7fa047725000 [GdkScreenX11], window=0x7fa04778f5a0 [GdkWindow]) at gdkscreen.c:315 #9 0x00007fa03ecfc7a8 in ?? () from /home/valdis/.mozilla/plugins/libflashplayer.so #10 0x00007fa03ed14543 in ?? () from /home/valdis/.mozilla/plugins/libflashplayer.so #11 0x00007fa03ecfe982 in ?? () from /home/valdis/.mozilla/plugins/libflashplayer.so #12 0x00007fa03ecfedd4 in ?? () from /home/valdis/.mozilla/plugins/libflashplayer.so Basically, it's just going bonkers beating on that libxcb.
Reporter | ||
Comment 2•12 years ago
|
||
I also noticed that with native flashplayer plugin, plugin-container constantly runs around 65% CPU on a 4-core computer.
Comment 3•12 years ago
|
||
Whatever the problem is/was, I can't replicate it anymore on the 01/23 trunk build.
Reporter | ||
Comment 4•12 years ago
|
||
Same here. Seems to be working now. I hope someone knows what fixed this, otherwise it is unsettling!
Comment 5•11 years ago
|
||
Resolving as WFM based on Comment 3 and Comment 4...
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•