Bugzilla – Bug 135973
Firefox crashes after installing the flash plug-in via the internet with site with flash content. Mozilla doesn't start u anymore.
Last modified: 2006-02-21 11:23:43 UTC
Firefox crashes after installing the flash plug in via the internet ona site with flash content: jboonen@sempron:~> firefox The program 'Gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 140 error_code 8 request_code 144 minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) jboonen@sempron:~> Mozilla doesn't start up anymore, after the plug in is installed in firefox: jboonen@sempron:~> mozilla LoadPlugin: failed to initialize shared library libXt.so [libXt.so: cannot open shared object file: No such file or directory] LoadPlugin: failed to initialize shared library /usr/X11R6/lib/libXt.so.6 [/usr/X11R6/lib/libXt.so.6: cannot open shared object file: No such file or directory] LoadPlugin: failed to initialize shared library libXext.so [libXext.so: cannot open shared object file: No such file or directory] LoadPlugin: failed to initialize shared library /usr/X11R6/lib/libXext.so.6 [/usr/X11R6/lib/libXext.so.6: cannot open shared object file: No such file or directory] /usr/bin/mozilla: line 259: 6302 Segmentation fault $MOZ_PROGRAM $MOZ_LANG jboonen@sempron:~> I presume only in x86-64 hardware.
looks similar to another bug (sorry not public available bug 135373)
Regardless...I can confirm that flash objects crash Firefox 1.5 and 1.5.0.1 on SUSE 10.1. Useing the rpm that comes with beta 1 it will not crash. Using either 1.5 or 1.5.0.1 from Mozilla.org will crash with either flash plugin 7.0r25 or 7.0r61 installed manually. All works normally in 10.0...this is strange behavior..and I would like to know what is different about the rpm that comes with the distro. I normally use the Mozilla versions.
Please check if the mozilla.org version crashes if you export XLIB_SKIP_ARGB_VISUALS=1 before starting it.
I don't have alpha4 not installed. Beta1 works perfectly with the standard flash. If needed i can install alpha4 again. But i'll take some time.
I am sorry that I didn't notice that this bug was for the 64 bit version..but the same bug happens in the 32 bit version: Bottom line...exporting that variable FIXES this issue. After exporting (this is in Beta 1) XLIB_SKIP_ARGB_VISUALS=1 the crash does NOT happen anymore. I wish I understood what the issue was, but this is right on..
To re-iterate..this BUG DID happen on the 32 bit version of beta 1 but exporting that variable fixes it. Also, this is only with the version of Firefox from Mozilla. The rpm version with the distro doesn't crash like this...
I am wondering what the status is on this...as this issue is still around in the 32-bit version of 10.1 beta 2. Good example is that the adobe.com front page will crash Firefox (mozilla version) unless XLIB_SKIP_ARGB_VISUALS=1 variable is first ecported. How will this issue affect the distribution (since I'm not sure exactly what that particular variable does over and above the normal environment). Will this be addressed? Is it just a minor issue or have you seen it be a problem with some other applications? How did you know that THIS particular export would solve the problem (unless you already have had some indication that this would be a problem?). I NEVER use the provided RPM's for Mozilla products, so this would be an important issue for some of us... Thanks... By the way, beta 2 is working great once the fontconfig fix was in....it's pretty much like the final product...wonderful!
Wolfgang, don't the X maintainers have a bug on this?
I'm not sure. At least it always helped to export XLIB_SKIP_ARGB_VISUALS=1.
Which is, for me, the question...what exactly does that do that makes the environment acceptable to Firefox/flash that isn't before. Additionally, why/how does the provided rpm with the distro not have this problem compaired to the Mozilla build (which is preferred by many). Some build option, I presume, but I haven't dug deep enough to know. I'll have to test this on Beta 3 more extensively..I plan on a clean install on my test machine, but I'll be out of town for tne majority of the testing week.
This is a bit lengthy: This is actually not a bug in X. It's a side effect of introducing semitransparent visuals. The way it has been introduced might break some applications (therefore the XLIB_SKIP_ARGB_VISUALS test). Until shortly, a display would typically only have visuals of a single depth, namely 8, 15, 16, or 24 bits. Theoretically (and on some SGI hardware practically) there could been several in parallel (deciding pixel depth on a per-pixel basis). Many programs just choose the visual of the highest depth. And many assume that to be less or equal to 24bits. Theoretically, a server could already present XRGB visuals (that is, 8bits don't have any meaning). With composite, these additional bits are now used for alpha (opacity=1-transparency), creating *additional* 32bit visuals (assuming 24bit truecolor visuals ATM). Software that is written correctly can deal with these 32bit visuals without crashing, even if they accidentially select it by default (though interesting effects happen, e.g. start xaos on Xgl - it gets completely transparent), but many allocate memory for 24bits only and can segfault. The correct way to deal with this is to allocate visuals with a maximum of 24bit *only*, and not the one with the highest pixel depth. Unfortunately, there hasn't been an easy way to allocate RGBA visuals in a backwards-compatible way, and I think that nowone wanted to add an additional request for alpha visuals. Thus XRGB visuals have been chosen to be used for them. Note that XRGB visuals *could* have been present before as well, so the code relying on a maximum of 24bits per pixel is broken anyway. Flash cannot be fixed by ourself, of course. I'm not 100% sure that this is the problem, but it is a likely explanation. I don't understand why this should have anything to do with x86_64, though, maybe it's just changing side effects due to different memory layouts. It also seems that the handling inside FireFox has changed so this bug finally comes to the surface.
(In reply to comment #10) > Which is, for me, the question...what exactly does that do that makes the > environment acceptable to Firefox/flash that isn't before. Additionally, > why/how does the provided rpm with the distro not have this problem compaired > to the Mozilla build (which is preferred by many). Some build option, I > presume, but I haven't dug deep enough to know. There is no difference in mozilla.org's build and ours. We simply export this variable in the start script. I think that it is Macromedia's flash player which doesn't work and so closing this. (BTW: I don't think it's x86-64 related. It also happens on x86 systems as far as I can tell)
(In reply to comment #12) > (In reply to comment #10) > > Which is, for me, the question...what exactly does that do that makes the > > environment acceptable to Firefox/flash that isn't before. Additionally, Forgot to comment that: The environment variable just prohibits the export of 32bit visuals if set. > (BTW: I don't think it's x86-64 related. It also happens on x86 systems as far > as I can tell) Ah. I see. Makes even more sense now.
And WONDERFUL explaination..and I appreciate it very much. It also tells me how to temporarily fix the problem. Just for the information, the later version of Flash 7 (I think it's 7.0r61) doesn't work either...I tested it with both the r25 and r61 version. Hopefully, the'll fix it. Thanks again for the very helpful information....bug closed.
I will try to push that fix upstream, and try to make some Flash developers aware of the problem.
Actually, it would be useful if you could check whether Flash 8 still has the problem. There is a Linux Flash 8 beta somewhere in Macromedia's website.
That's a great idea...I only have one problem with it. I'm out of town for the entire week completely away from my test computer. I won't be back until Friday late night...so if I find that file and try it, it will take a while from now...but if I do, I'll post the results...I still have beta 2 on that computer and will for a while since I have gotten a bit busy. But I'll try to test FLASH 8 on it and see what happens..
Hi Guys....even though tagged resolved/fixed...I thought that I would write just to confirm, since I said that I would get back to you. I didn't have to try the beta of flash, since in beta 4 now, there is no problem with Firefox (an version) and flash....it's not crashing anymore with flash objects...so whatever fixed it in the base system (if anything)...it's working now! So this is to confirm that this bug should be closed, if you feel that is the proper action item...