Segfault in cairo_draw_with_xlib

[Joel Stanley]

Binary package hint: firefox-3.0

Ubuntu Hardy 64bit, latest updates as of 2008-06-11.

firefox: 3.0~rc1+nobinonly-0ubuntu0.8.04.1
xulrunner: 1.9~rc1+nobinonly-0ubuntu1~8.04.2

Backtrace attached.

=================
Update 13/8/08: Including a more useful description.

The crashes experienced in this bug are caused by Firefox 3 (really xulrunner-1.9) which has buggy "windowless mode" support. Adobe Flash 10 (since beta 2) and recent versions of swfdec are the first plugins to make use of "windowless mode", and attempting to visit flash-enabled sites that use "windowless mode" will cause an immediate segmentation fault when rendering wmode flash content on the page. See: http://blogs.adobe.com/penguin.swf/2008/07/addessing_wmode_crashes.html

This issue is has been fixed upstream and due for release in xulrunner 1.9.0.2, and Felix Geyer has successfully patched Hardy's xulrunner 1.9.0.1 for testing purposes. You can check these packages at: http://ppa.launchpad.net/sniperbeamer/ubuntu/pool/main/x/xulrunner-1.9/

It is important to be aware of this issue in xulrunner-1.9 to avoid the inevitable confusion with bug #192888. This bug is a separate issue, and many users will encounter this bug as a side-effect of upgrading to Flash 10, which is necessary to fix bug #192888.

[Sylvain BERTRAND (sylvain-bertrand)]

Created attachment 322523
gdb bt full with a debug build of firefox 3.0 RC1

[Benjamin Otte (Company) (otte)]

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

[Sylvain BERTRAND (sylvain-bertrand)]

Crash with same BT:
http://www.universfreebox.com/article5360.html

[Sylvain BERTRAND (sylvain-bertrand)]

Made a full debug build of firefox 3 RC2 with today git swfdec:
 - http://www.leparisien.fr seems not to crash anymore.
 - http://www.universfreebox.com/article5360.html hangs the whole firefox process.

[Karlt (karlt)]

I'm keen to try out swfdec, but I haven't found a revision of
git://swfdec.freedesktop.org/git/swfdec/swfdec in the last few days that compiles.

Can someone recommend a revision/tag that I should use, please?

BTW, the current issue is:
cc1: warnings being treated as errors
swfdec_init.c: In function 'swfdec_init':
swfdec_init.c:68: warning: implicit declaration of function 'strtoul'
swfdec_init.c:68: warning: nested extern declaration of 'strtoul'

[Joel Stanley (shenki)]

Binary package hint: firefox-3.0

Ubuntu Hardy 64bit, latest updates as of 2008-06-11.

firefox: 3.0~rc1+nobinonly-0ubuntu0.8.04.1
xulrunner: 1.9~rc1+nobinonly-0ubuntu1~8.04.2

Backtrace attached.

[Marcus Asshauer (mcas)]

Thank you for reporting this bug.
Please answer these questions:
Is this crash reproducible? If so, which are the steps that lead to it?
Which flash package do you have installed?
Which Java package do you have installed?
Which Firefox extensions do you have installed?

This will greatly aid us in tracking down your problem.

[Benjamin Otte (Company) (otte)]

Uh yeah, you're in a kind of peculiar situation here as you need to run a development version, and those set -Werror (and no, I'm not going into a discussion of why this is the best thing people should do). In theory, git master should work (and definitely compile) fine, as there's enough developers running it every day. If there's issues, poke me on IRC and I'll fix them immediately.

That said, if you still want the easy path, export CFLAGS=-Wno-error when building swfdec and swfdec-mozilla. That gets rid of the "warnings being treated as errors" thing.

[Alexander Sack (asac)]

On Wed, Jun 11, 2008 at 02:07:34PM -0000, Joel Stanley wrote:
> Public bug reported:
>
> Binary package hint: firefox-3.0
>
> Ubuntu Hardy 64bit, latest updates as of 2008-06-11.
>
> firefox: 3.0~rc1+nobinonly-0ubuntu0.8.04.1
> xulrunner: 1.9~rc1+nobinonly-0ubuntu1~8.04.2

what does running

dpkg -l libcairo2

on a terminal give you?

 status incomplete

 - Alexander

[Joel Stanley (shenki)]

I could reproduce every time by visiting this URL: http://www.last.fm/music/The+Herd/_/Toorali

* libcairo1.6.0-0ubuntu1
* icedtea-gcjwebplugin 1.0-0ubuntu5
* libswfdec-0.7-0 0.7.1~20080523 (this comes from https://launchpad.net/~juliank/+archive)

Extensions installed
 * adblock plus
 * ubuntu firefox modifications.

[Alexander Sack (asac)]

On Thu, Jun 12, 2008 at 04:01:41AM -0000, Joel Stanley wrote:
> I could reproduce every time by visiting this URL:
> http://www.last.fm/music/The+Herd/_/Toorali
>
> * libcairo1.6.0-0ubuntu1
> * icedtea-gcjwebplugin 1.0-0ubuntu5
> * libswfdec-0.7-0 0.7.1~20080523 (this comes from https://launchpad.net/~juliank/+archive)

ok, assigning cairo for now.

Does changing your video driver help? Try to switch from Option
"AccelMethod" "EXA" to "XXA" or vv.

 status incomplete

 - Alexander

[Joel Stanley (shenki)]

Changing to XAA didn't help at all.

Removing swfdec, firefox defaults back to gnash which doesn't crash.

Thanks Benjamin for the link to the mozilla bug.

[Karlt (karlt)]

Thanks to Benjamin, I now have swfdec-mozilla compiled (and producing some
nice effects when Mozilla doesn't crash).

The crash is happening because sometimes ws_info is not set up (in
nsObjectFrame::CallSetWindow()) and so it contains zeros when used in
nsPluginInstanceOwner::Paint().

The crash happens for plugins that are instantiated through
nsObjectFrame::Instantiate(nsIChannel* aChannel, nsIStreamListener** aStreamListener)
rather than
nsObjectFrame::Instantiate(const char* aMimeType, nsIURI* aURI)
as only the later does CallSetWindow() (and I don't know why that is).

With attachment 324576, gfxXlibNativeRenderer::Draw almost never uses its dpy
argument and so the crash reduces to

###!!! ASSERTION: Visual changed: colormap may not match: 'ws_info->visual == visual', file /home/karl/moz/mozilla/layout/generic/nsObjectFrame.cpp, line 4207

but still no useful info is available in ws_info for the plugin.

I can reproduce the assertion when scrolling to the first windowless plugin on
http://www.universfreebox.com/article5360.html, or on http://movies.yahoo.com/.

[Karlt (karlt)]

Created attachment 324752
move ws_info set up from nsObjectFrame::CallSetWindow() to nsPluginInstanceOwner::CreateWidget()

This is one way to solve the problem.
Perhaps another is to set up in nsObjectFrame::FixupWindow, or perhaps both
nsObjectFrame::Instantiate methods (or neither) should do CallSetWindow();

The build here has this patch and attachment 324576, for those who would like something that works:

https://build.mozilla.org/tryserver-builds/2008-06-11_23:<email address hidden>/

(I'll see if I can work out why the Instantiate methods differ.)

[Jonas-sicking (jonas-sicking)]

Is this a common way to view flash on linux? Or are people just using the official macromedia one?

[Karlt (karlt)]

(In reply to comment #9)

The bug is being hit because newer versions of swfdec have windowless support.

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/239182

The macromedia plugin will hit the same bug when it has wmode support.

(I don't know how many users use use swfdec or gnash or the macromedia plugin [with nspluginwrapper for 64-bit].)

[Karlt (karlt)]

(In reply to comment #8)
A better build with attachment 324914 (which fixes the plugin height) and attachment 324752:

https://build.mozilla.org/tryserver-builds/2008-06-12_19:<email address hidden>/

[Mike Melanson (mmelanso-adobe)]

Similar problem seen in Adobe Flash Player. Most notable with http://movies.yahoo.com/ . Tracked by Adobe internal issue 228012.

[Karlt (karlt)]

This will happen with any windowless plugin when the mime type is determined from using the URL in the data attribute rather than from the
type attribute, which now happens for object elements (bug 95549).
I guess there would be the same problem if the type attribute were not included in an embed element.

[Karlt (karlt)]

Created attachment 327742
move ws_info set up from nsObjectFrame::CallSetWindow()

nsPluginInstanceOwner::CreateWidget() is a good place to set up the display because that is where the plugin "becomes" windowless, and the display should not change.

The right place to set up the Colormap is in nsPluginInstanceOwner::Renderer::NativeDraw() where the Visual is known.

To avoid the need to hunt for the Visual on the Display to find the
Screen for selecting a Colormap, this changes the Display* argument of gfxXlibNativeRenderer::NativeDraw to a Screen*.

This also makes the treatment of CAIRO_XLIB_DRAWING_SUPPORTS_NONDEFAULT_VISUAL in _create_temp_xlib_surface consistent with that in _draw_with_xlib_direct.
i.e. when not set the visual must be the default visual of the screen used,
but need not be the default visual of the fallback dpy specified.

[Mike Melanson (mmelanso-adobe)]

Reported by Adobe Flash Player users:
http://nvidia.com/
http://www.bbc.co.uk/
I reproduced these crashes by loading the pages and then maximizing the browser frame. The crash appears to come from libxul.so.

[Stephanie Daugherty (sdaugherty-deactivatedaccount)]

I'm seeing an almost identical crash with latest Adobe Flash Player on my own personal blog, which is fixed by Karl's test build. I can reproduce 100% on latest nightly by scrolling down the page.
http://crash-stats.mozilla.com/report/index/ec6a48d1-4a4b-11dd-b681-001cc45a2ce4 and http://crash-stats.mozilla.com/report/index/d95b1702-4a4c-11dd-a703-001cc45a2ce4 are two of my crashes from a nightly.

[Gnorton (gnorton)]

I think my bug #442115 is a duplicate of this with some additional information as to what is causing this.

[Karlt (karlt)]

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

[Roc-ocallahan (roc-ocallahan)]

FindColormapForVisual and the other colormap-getting machinery should move into gfxNativeRenderer as discussed. Otherwise looks great. (X suuuuucks!)

[Karlt (karlt)]

Created attachment 328287
move ws_info set up from nsObjectFrame::CallSetWindow() v4.1

(In reply to comment #19)
> FindColormapForVisual and the other colormap-getting machinery should move into
> gfxNativeRenderer as discussed.

Done.

[Karlt (karlt)]

Requesting blocking 1.9.0.2 because both swfdec and Adobe now have
windowless-capable Flash plugins available (though Adobe's at least is still in
beta), and moonlight also has a windowless plugin.

The number of affected sites is hard to estimate as there is a race condition between reflow and plugin instantiation, but definitely high enough that we can expect plenty of users to hit this when they upgrade their plugin versions.

[Gnorton (gnorton)]

Confirmed the latest patch fixes this issue with the moonlight plugin and our testcases.

@karlt, The patch doesn't appear to apply cleanly with any version of patch tho, dunno whats going on with that.

[Karlt (karlt)]

Created attachment 328388
move ws_info set up from nsObjectFrame::CallSetWindow() v4.1.1

Correct patch line counts. (Same code.)

(In reply to comment #22)
> The patch doesn't appear to apply cleanly with any version of patch
> tho, dunno whats going on with that.

Thanks for testing, Geoff. Sorry about the patch. Emacs diff-mode sometimes (but I don't know exactly when) doesn't update line counts and I forgot to check that.

[Karlt (karlt)]

Created attachment 328437
include gdk/gdkscreen.h in system-headers

for:

/tools/gcc/bin/g++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -gstabs+ -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions -finline-limit=50 -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsCompressedCharMap.o nsBidiUtils.o nsRDFResource.o -lpthread -Wl,-rpath-link,../../dist/bin -Wl,--whole-archive ../../embedding/browser/gtk/src/libgtkembedmoz.a ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libxpconnect.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libpref.a ../../staticlib/components/libcaps.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libchrome.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libmozfind.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libxpinstall.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/libcomposer.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libintlapp.a ../../staticlib/components/libfileview.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libucvmath.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libsystem-pref.a ../../staticlib/components/libgkgfxthebes.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libgkgfx.a ../../staticlib/libgfxshared_s.a ../../staticlib/libmozreg_s.a ../../staticlib/libmorkreader_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libgfxpsshar.a ../../staticlib/libthebes.a -Wl,--no-whole-archive -L../../dist/lib -lsqlite3 -L../../dist/bin -L../../dist/lib -L../../dist/bin -L../../dist/lib -L../../jpeg -lmozjpeg -L../../mo...

[Karlt (karlt)]

pushed:
http://hg.mozilla.org/index.cgi/mozilla-central/rev/9bbea3b66376
http://hg.mozilla.org/index.cgi/mozilla-central/rev/e30f2c0b5c1f
http://hg.mozilla.org/index.cgi/mozilla-central/rev/6c0971153949

[Mike Melanson (mmelanso-adobe)]

Another consistent crasher: http://skoda-auto.cz/

[Karlt (karlt)]

Please use the build here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-07-08-02-mozilla-central/

It includes the fix for this bug
(and resolves the crash on http://skoda-auto.cz/).

[Mike Melanson (mmelanso-adobe)]

Awesome. Works great with all of the problem URLs. Thanks.

[Felix Geyer (debfx)]

I can reproduce this bug with Adobe Flash 10.

The 3 patches mentioned in the upstream bugreport definitely fix the issue (tested with patched xulrunner 1.9 and firefox 3.0):
http://hg.mozilla.org/index.cgi/mozilla-central/rev/9bbea3b66376
http://hg.mozilla.org/index.cgi/mozilla-central/rev/e30f2c0b5c1f
http://hg.mozilla.org/index.cgi/mozilla-central/rev/6c0971153949

So it's not a firefox but a xulrunner bug.

[Conn O Griofa (psyke83)]

Confirmed Felix's observations. This is a bug with wmode (windowless mode) in Firefox 3.0.

This bug is exposed in Flash 10 beta 2 (the first release that supports wmode) and new releases of swfdec (also with wmode support), and it is not related to PulseAudio or libflashsupport (a previous cause of crashes with Flash). The issue affects 32bit and 64bit systems, but nspluginwrapper prevents the entire firefox process from dying for 64bit users, so the bug is more difficult to isolate for 64bit users.

This blog entry from Adobe confirms these findings: http://blogs.adobe.com/penguin.swf/2008/07/addessing_wmode_crashes.html

[Stephen-moehle (stephen-moehle)]

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

[John Vivirito (gnomefreak)]

For now flash 9 has been pushed back to Hardy as flash doesnt seem to be as ready for everyone as it is for me.

[Conn O Griofa (psyke83)]

John, agreed it's better to leave Hardy alone.

As for Intrepid, this bug still exists. The solution is to either wait for Firefox 3.0.1 (although I'm not sure it will include the fix), or manually backport the changes as mentioned by Felix (and on the upstream bug). Intrepid already has up-to-date alsa-lib files, so once bug #198453 is fixed (to set the proper .asoundrc), Flash will work correctly, and libflashsupport (see bug #192888) will no longer be a requirement to get PulseAudio output working.

[Felix Geyer (debfx)]

Firefox 3.0.1 doesn't include the fix (at least the build1).
I think the problem is, that the patches change a public header file (gfxXlibNativeRenderer.h), which might break applications that depend on xulrunner.

[Andrew Melo (andrew-melo)]

@ Conn

I had to upgrade to flash 10 to solve some audio issues I had with 9. Is there a chance of having the wmode patches being backported to hardy-proposed?

[Karlt (karlt)]

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

[Conn O Griofa (psyke83)]

Andrew,

(This is a bit off-topic). I'm only a user, not a maintainer or developer, so I can't tell you if it will get backported (by the way, backports would go into hardy-backports; the purpose of hardy-proposed is to test releases that may be considered for hardy-updates). In my opinion, there's not much chance of this getting solved in Hardy soon. I recommend you keep Flash 9, configure PulseAudio correctly, and configure Flash to use PulseAudio output. Part B of this guide will explain it: http://ubuntuforums.org/showthread.php?t=789578

[Andrew Melo (andrew-melo)]

Conn, thanks for the reply. The reason I was asking is because the wmode glitch has been fixed in the upstream packages since (IIRC) the 5th of July, so I didn't know if they were going to filter down to the current packages.

[Samuel-sidler+old (samuel-sidler+old)]

Can we get a test for this before landing in 1.9.0?

[Karlt (karlt)]

(In reply to comment #31)
Automated testing depends on having a windowless plugin in our source tree
(bug 386144).

I've manually tested this patch with Swfdec on the problem sites reported
here, Geoff Norton has tested the Moonlight plugin (comment #22) on their
testcases (including attachment attachment 326988), and Mike Melanson has
tested the Adobe plugin (comment #28).

[Samuel-sidler+old (samuel-sidler+old)]

Comment on attachment 328388
move ws_info set up from nsObjectFrame::CallSetWindow() v4.1.1

Approved for 1.9.0.2. Please land in CVS. a=ss

[Samuel-sidler+old (samuel-sidler+old)]

Comment on attachment 328437
include gdk/gdkscreen.h in system-headers

Approved for 1.9.0.2. Please land in CVS. a=ss

[Samuel-sidler+old (samuel-sidler+old)]

No blocking, but wanted (and the patches are already approved).

[Karlt (karlt)]

Comment on attachment 328388
move ws_info set up from nsObjectFrame::CallSetWindow() v4.1.1

checked into cvs with attachment 328437:

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=%2Fcvsroot&date=explicit&mindate=1216938963&maxdate=1216939084&who=karlt%2B%25karlt.net

[Felix Geyer (debfx)]

I applied the patches from the upstream bug report to xulrunner-1.9. It works fine for me.
You can download the patched packages from my PPA: http://ppa.launchpad.net/sniperbeamer/ubuntu/pool/main/x/xulrunner-1.9/

[Conn O Griofa (psyke83)]

Felix,

I tested your xulrunner and xulunner-1.9-gnome-support packages versions 1.9.0.1+build1+nobinonly-0ubuntu0.8.04.2+ppa1 on Intrepid (I do not have Hardy installed at the moment) and they indeed fix crashes on common sites with Flash v10 beta 2 (10.0.1.218+10.0.0.525ubuntu1). Thanks!

By the way, recent activity on the upstream bug seems to suggest the patches may be included in xulrunner 1.9.0.2.

[Andrew Melo (andrew-melo)]

felix,

I've tested the packages from your PPA, and with the flash10 beta, I consistently get the following output from firefox (followed by it vanishing)

amelo@amelo-laptop:~$ firefox http://www.youtube.com
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
Segmentation fault
amelo@amelo-laptop:~$ *** NSPlugin Viewer *** ERROR: NPP_SetWindow() get args: Connection closed

I'm not sure where to core goes when firefox segfaults, or I'd show you some other data.

Any suggestions?
Andrew

[Wade Menard (wade-ezri)]

Andrew: I can't give a solution, but the Message: GetValue's are from Totem and harmless. The NSPlugin error is from nspluginwrapper.

[Felix Geyer (debfx)]

Are you using the nspluginwrapper 1.1.0 beta?
That's the only version which supports windowless plugins.

[Andrew Melo (andrew-melo)]

Felix:

Is this the correct version?

amelo@amelo-laptop:~$ dpkg --list | grep nspluginwrapper
ii nspluginwrapper 1.1.0-0conn2 A wrapper to run Netscape plugins on other a

[Conn O Griofa (psyke83)]

Andrew,

You're using i386? If so, nspluginwrapper isn't necessary - I built that package for testing purposes. Remove nspluginwrapper and flashplugin-nonfree, then reinstall flashplugin-nonfree.

Also, I have *never* seen Youtube crash from this particular bug, so you may likely have another problem. Do you have "libflashsupport" installed?

It's not a good idea to ask for support in Launchpad bug reports like this, as it pollutes the comments. Ubuntu Forums may be a better place. See this thread: http://ubuntuforums.org/showthread.php?t=866965

[Andrew Melo (andrew-melo)]

@Conn
Sorry if I didn't articulate myself well, but I wasn't looking for support. I was just trying to make sure I had the same combination of packages installed so I could help diagnose the problem.

I'm on i386, and I was following a separate howto that suggested I install nspluginwrapper to solve issues with pulse + flash.

Using the latest xulrunner from hardy-proposed and felix's PPA, I still get a hard lock when viewing certain sites, it's not always repeatable, however.

[Conn O Griofa (psyke83)]

From: http://blogs.adobe.com/penguin.swf/2008/08/windowless_mode_fix.html

"As a reminder, Firefox 3.0.1 has a known crash problem with a wide variety of windowless mode SWFs. This has already been fixed in the Mozilla code tree and alpha builds are available for download. However, if you would prefer to wait until a new official Firefox release, you may wish to disable windowless mode in the Flash Player. You can do this (on any platform) by setting WindowlessDisable=true in the mms.cfg (which lives in /etc/adobe on Unix platforms)."

I have uploaded a deb for the latest release candidate for Flash to my PPA that disables windowless mode via this method (the way it's done is a little hacky, but it works). I can confirm it stops these crashes entirely.

https://launchpad.net/~psyke83/+archive

Disabling wmode is highly recommended at the moment because a) we need to wait for Firefox 3.0.2 and b) 64bit users will need the latest development release (>=1.1.0) of nspluginwrapper that supports windowless mode, which isn't available in the repositories yet.

[Marcos Felipe Mello (marcosfrm)]

Too much for Firefox 3.0.2 release?

Bacause with this fixed and a backported Alsa (using pulse plugin), all the problems with Flash are solved!

[Marcos Felipe Mello (marcosfrm)]

Using Flash 10 of course....

[Jonne (jonathan-vanherpe)]

This might be OT, but it seems like updating to Felix' ppa packages of xulrunner disabled my extensions. Firefox keeps telling me to restart to apply changes, while restarting (even the whole os) doesn't fix anything. Anyone else have that?

[Matteo Settenvini (tchernobog)]

I tried Conn's flashplugin-nonfree package in comment #23, and it doesn't solve the issue for me.
More, epiphany-gecko for some reason seems to present this issue far more frequently than firefox.
Simply browsing youtube a little or opening and then closing a couple of tabs with flash video in them, makes all gecko browsers go down.

Attaching a stacktrace for epiphany (the one for firefox is mostly identical to the one already provided).
This happens on the website onepieceworld.net, simply waiting for the page to load and scrolling it for some time. But it happens also on a lot of other websites, too.

[Conn O Griofa (psyke83)]

Matteo,

There are multiple issues that can impact Flash at the moment. You must also ensure you are not using "libflashsupport"; see bug #192888 (and from the symptoms you describe, it seems more likely to be your problem).

Browsing the site you mentioned, I see no problems on my systems with the workaround in place *and* libflashsupport disabled. I do see a lot of embedded Youtube videos that can trigger the crash as mentioned in the other bug, though.

[Matteo Settenvini (tchernobog)]

Thank you Conn, you were obviously right. I missed it because the libflashsupport I had installed didn't come in a debian package in my system, so looking at, say, aptitude, made me think it wasn't installed here. I was wrong. It's indeed fixed removing libflashsupport and using the modified flash packages.
Thanks.

[Michael Onnen (michael-onnen)]

This seems to be fixed in hardy with the security updates that came in today
firefox-3.0 (3.0.2+build6+nobinonly-0ubuntu0.8.04.1)
xulrunner-1.9 (1.9.0.2+build6+nobinonly-0ubuntu0.8.04.1)

WindowlessDisable=true
in /etc/adobe/mms.cfg is no longer necessary

[nullack (nullack)]

Fix release, issue resolved. Noting also that xulrunner 1.9.03 is now in Intrepid.

[surfed (god-youhavechoice)]

Hmm I am running Firefox 3.0.3+build1+nobinonly-0ubuntu1 with xulrunner 1.9.0.3+build1+nobinonly-0ubuntu2 and still need windowlessmode=1 to get flash to work on 64 bit. Without it i just get the famous gray box. With it i get beautiful Flash 10.

[leps (patrick-lepore)]

I'm noticing this problem in 8.10 also. The gray box for some sites with flash. Was the fix also supposed to work in 8.10?