If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Native 64-bit flash player 11 plugin does not work anymore

RESOLVED WORKSFORME

Status

()

Firefox
Untriaged
RESOLVED WORKSFORME
6 years ago
5 years ago

People

(Reporter: Mahesh Asolkar, Unassigned)

Tracking

12 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 589332 [details]
Screenshot of corrupt flash display

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

6 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

6 years ago
I also noticed that with native flashplayer plugin, plugin-container constantly runs around 65% CPU on a 4-core computer.

Comment 3

6 years ago
Whatever the problem is/was, I can't replicate it anymore on the 01/23 trunk build.
(Reporter)

Comment 4

6 years ago
Same here. Seems to be working now. I hope someone knows what fixed this, otherwise it is unsettling!

Comment 5

5 years ago
Resolving as WFM based on Comment 3 and Comment 4...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.