Segfault in cairo_draw_with_xlib
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Mozilla Firefox |
Fix Released
|
Critical
|
||
| | firefox-3.0 (Ubuntu) |
Undecided
|
Unassigned | ||
| | flashplugin-nonfree (Ubuntu) |
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: firefox-3.0
Ubuntu Hardy 64bit, latest updates as of 2008-06-11.
firefox: 3.0~rc1+
xulrunner: 1.9~rc1+
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://
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://
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.
|
|
#2 |
*** Bug 435838 has been marked as a duplicate of this bug. ***
Crash with same BT:
http://
Made a full debug build of firefox 3 RC2 with today git swfdec:
- http://
- http://
|
|
#5 |
I'm keen to try out swfdec, but I haven't found a revision of
git://swfdec.
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'
Binary package hint: firefox-3.0
Ubuntu Hardy 64bit, latest updates as of 2008-06-11.
firefox: 3.0~rc1+
xulrunner: 1.9~rc1+
Backtrace attached.
| Joel Stanley (shenki) wrote : | #7 |
| Marcus Asshauer (mcas) wrote : | #8 |
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.
| Changed in firefox-3.0: | |
| status: | New → Incomplete |
|
|
#9 |
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.
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+
> xulrunner: 1.9~rc1+
what does running
dpkg -l libcairo2
on a terminal give you?
status incomplete
- Alexander
I could reproduce every time by visiting this URL: http://
* libcairo1.
* icedtea-
* libswfdec-0.7-0 0.7.1~20080523 (this comes from https:/
Extensions installed
* adblock plus
* ubuntu firefox modifications.
On Thu, Jun 12, 2008 at 04:01:41AM -0000, Joel Stanley wrote:
> I could reproduce every time by visiting this URL:
> http://
>
> * libcairo1.
> * icedtea-
> * libswfdec-0.7-0 0.7.1~20080523 (this comes from https:/
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
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.
| Changed in firefox: | |
| status: | Unknown → Confirmed |
|
|
#14 |
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:
nsPluginInstanc
The crash happens for plugins that are instantiated through
nsObjectFrame:
rather than
nsObjectFrame:
as only the later does CallSetWindow() (and I don't know why that is).
With attachment 324576, gfxXlibNativeRe
argument and so the crash reduces to
###!!! ASSERTION: Visual changed: colormap may not match: 'ws_info->visual == visual', file /home/karl/
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://
|
|
#15 |
Created attachment 324752
move ws_info set up from nsObjectFrame:
This is one way to solve the problem.
Perhaps another is to set up in nsObjectFrame:
nsObjectFrame:
The build here has this patch and attachment 324576, for those who would like something that works:
https:/
(I'll see if I can work out why the Instantiate methods differ.)
|
|
#16 |
Is this a common way to view flash on linux? Or are people just using the official macromedia one?
|
|
#17 |
(In reply to comment #9)
The bug is being hit because newer versions of swfdec have windowless support.
https:/
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].)
|
|
#18 |
(In reply to comment #8)
A better build with attachment 324914 (which fixes the plugin height) and attachment 324752:
https:/
Similar problem seen in Adobe Flash Player. Most notable with http://
|
|
#20 |
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.
|
|
#21 |
Created attachment 327742
move ws_info set up from nsObjectFrame:
nsPluginInstanc
The right place to set up the Colormap is in nsPluginInstanc
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 gfxXlibNativeRe
This also makes the treatment of CAIRO_XLIB_
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.
Reported by Adobe Flash Player users:
http://
http://
I reproduced these crashes by loading the pages and then maximizing the browser frame. The crash appears to come from libxul.so.
| Changed in firefox: | |
| status: | Confirmed → In Progress |
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://
|
|
#24 |
I think my bug #442115 is a duplicate of this with some additional information as to what is causing this.
|
|
#25 |
*** Bug 442115 has been marked as a duplicate of this bug. ***
|
|
#26 |
FindColormapFor
|
|
#27 |
Created attachment 328287
move ws_info set up from nsObjectFrame:
(In reply to comment #19)
> FindColormapFor
> gfxNativeRenderer as discussed.
Done.
|
|
#28 |
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.
|
|
#29 |
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.
|
|
#30 |
Created attachment 328388
move ws_info set up from nsObjectFrame:
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.
|
|
#31 |
Created attachment 328437
include gdk/gdkscreen.h in system-headers
for:
/tools/gcc/bin/g++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-
| Changed in firefox: | |
| status: | In Progress → Fix Released |
Another consistent crasher: http://
|
|
#34 |
Please use the build here:
http://
It includes the fix for this bug
(and resolves the crash on http://
Awesome. Works great with all of the problem URLs. Thanks.
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://
http://
http://
So it's not a firefox but a xulrunner bug.
| Changed in firefox-3.0: | |
| status: | Incomplete → Confirmed |
| Conn O Griofa (psyke83) wrote : | #37 |
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://
*** Bug 445043 has been marked as a duplicate of this bug. ***
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) wrote : | #40 |
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) wrote : | #41 |
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 (gfxXlibNativeR
| Andrew Melo (andrew-melo) wrote : | #42 |
@ 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?
|
|
#43 |
*** Bug 445202 has been marked as a duplicate of this bug. ***
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://
| Andrew Melo (andrew-melo) wrote : | #45 |
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.
Can we get a test for this before landing in 1.9.0?
|
|
#47 |
(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).
Comment on attachment 328388
move ws_info set up from nsObjectFrame:
Approved for 1.9.0.2. Please land in CVS. a=ss
Comment on attachment 328437
include gdk/gdkscreen.h in system-headers
Approved for 1.9.0.2. Please land in CVS. a=ss
No blocking, but wanted (and the patches are already approved).
|
|
#51 |
Comment on attachment 328388
move ws_info set up from nsObjectFrame:
checked into cvs with attachment 328437:
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://
| Conn O Griofa (psyke83) wrote : | #53 |
Felix,
I tested your xulrunner and xulunner-
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) wrote : | #54 |
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-
** 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-
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) wrote : | #55 |
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) wrote : | #56 |
Are you using the nspluginwrapper 1.1.0 beta?
That's the only version which supports windowless plugins.
| Andrew Melo (andrew-melo) wrote : | #57 |
Felix:
Is this the correct version?
amelo@amelo-
ii nspluginwrapper 1.1.0-0conn2 A wrapper to run Netscape plugins on other a
| Conn O Griofa (psyke83) wrote : | #58 |
Andrew,
You're using i386? If so, nspluginwrapper isn't necessary - I built that package for testing purposes. Remove nspluginwrapper and flashplugin-
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://
| Andrew Melo (andrew-melo) wrote : | #59 |
@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.
| description: | updated |
| Conn O Griofa (psyke83) wrote : | #60 |
From: http://
"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 WindowlessDisab
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:/
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) wrote : | #61 |
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) wrote : | #62 |
Using Flash 10 of course....
| Jonne (jonathan-vanherpe) wrote : | #63 |
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) wrote : | #64 |
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) wrote : | #65 |
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) wrote : | #66 |
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) wrote : | #67 |
This seems to be fixed in hardy with the security updates that came in today
firefox-3.0 (3.0.2+
xulrunner-1.9 (1.9.0.
WindowlessDisab
in /etc/adobe/mms.cfg is no longer necessary
| nullack (nullack) wrote : | #68 |
Fix release, issue resolved. Noting also that xulrunner 1.9.03 is now in Intrepid.
| Changed in firefox-3.0: | |
| status: | Confirmed → Fix Released |
| Changed in flashplugin-nonfree: | |
| status: | New → Fix Released |
| surfed (god-youhavechoice) wrote : | #69 |
Hmm I am running Firefox 3.0.3+build1+
| leps (patrick-lepore) wrote : | #70 |
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?
| Changed in firefox: | |
| importance: | Unknown → Critical |
Created attachment 322523
gdb bt full with a debug build of firefox 3.0 RC1