342083 - firefox crashes X server (xorg) on x86_64 linux

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Jonathan Baron]

This site leads to a crash of the x server on Fedora Core 5, x68_64, but NOT on i386.  The two computers seem identical.  Both have jre-1.5.0_06-fcs installed but I don't think this site uses Java.  Unfortunately, the crash does not happen every time.  When it happens, it is as if I used gdm-restart.

This is NOT the same bug as bug 304711, because the test case works.  It is not the same as bug 340521 because that evokes talkback, and this bug does not.

Comment 1

[Adam Guthrie]

Could you build a debug build and get a stack trace for this? Do you see anything printed to the console when you crash?

Comment 2

[timeless]

if your x server dies, that's usually a bug in your x server. this bug database doesn't track bugs in x servers in general, nor are we experts at debugging crashes in them.

start by getting a debug build (or at least a symboled build) of your xserver and using ulimit -c unlimited before manually running X on :1 or something. then run just X on :1 and firefox in it. when you crash. follow your xserver's instructions (which shouldn't involve you contacting us here). once you've resolved your crash in the xserver, please inform us of the bug# referencing the fix in your xserver's bug database so that we can close this bug.

note that i'm slightly disappointed that this bug is filed as new.

why would you as someone with canconfirm think that a crash in an xserver is our fault and something we should deal with?

Comment 3

[Jonathan Baron]

I wrote a reply to the last comment #2 and tried to send it by email, since some of it was about the ad hominem part.  It didn't go through.  Just as well.  The gist was that I might take some of these suggestions when I have time, but I'm hoping that the problem gets better by itself before then.

In the meantime, the last time I tested it, it crashed the whole computer, not just the X server.  I got a "kernal panic."  In a few days I will get up the courage to try again, but it now seems that it is much harder to determine where the bugs are.  I suspect there is more than one bug, and one of them is likely to be in Firefox (Minefield).

It would be nice if someone else using x86_64 linux would test this to see if it is a real bug (wherever it is).

Comment 4

[Jonathan Baron]

I still have not had time to try the debug build (or figure out where to find one), but I have more information.  Three sites now cause this crash somewhat reliably (and no longer cause kernel panic, ever).  One is the original weather site listed above.  The other is www.princeton.edu (in the last day or two).  The third is http://www.sas.upenn.edu/~twilkins.  All three have an image that, most of the time, looks garbled when I view it on another computer (32 bit - the crashes occur only on a 64 bit Intel computer).  Looking at the Error console (on the other computer) reveals no common error messages, and I can see nothing that the three images have in common.

Comment 5

[Jonathan Baron]

Still more information.  If I turn off images in Preferences, so that the images do not load, the sites in question do not crash.  And I can view the offending images by right-clicking on them and selecting View image.  Thus, the problem is caused by something about the way images are embedded in the page, not by the image viewing mechanism itself.  I believe that they are all resized, but other resized images work fine (now).  If I had to guess where this bug is, based on my VERY limited knowledge, I would say Cairo.  (Earlier, there were problems with resized images, now fixed, and they were architecture specific.)

Comment 6

[Jonathan Baron]

More information: I had been using kmod-fglrx and xorg-x11-drv-fglrx for video driver.  Because they are no longer updating kmod-fglrx for new kernels, I switched to the radeon driver that came with the kernel.  Now I get no more crashes.  Instead, the images that caused trouble before are now replaced with some apparently random selection of something I had been looking at preveiously.  For example, the image in http://www.sas.upenn.edu/~twilkins/Welcome.html is replaced, every time, with something else.  But if I right-click on the space where the image is supposed to be and select view-image, I can see the correct image.

Comment 7

[Adam Guthrie]

Sounds like bug 334951.

Comment 8

[Jonathan Baron]

(In reply to comment #7)
> Sounds like bug 334951.

That bug is closed, so I will continue to comment here.  (There was supposed to be another bug, but I can't find it.)

Yes.  What appears to trigger this bug is resizing, just as in the case of bug 334951.  Compare
http://www.sas.upenn.edu/~twilkins/Welcome.html
and
http://www.sas.upenn.edu/~baron/tess/Welcome.html

In the first one, the image does not display.  In the second, it does.  All I did was change the width property of the image (search for "photo") from 330px to 329px.  The image is actually 329px.

However, resizing alone is not sufficient to trigger this problem.  In the case of bug 334951, no resized images would work.  Now, surely, 99% of them work, and I have yet to figure out what makes the others fail.  (It isn't, for example, that the size is off by 1px.  I tried other values of width and the all fail.)

Moreover, it seems that the effect of this bug (or bugs) is different with different video drivers and even different hardware.  The crash with this particular web page happens with fglrx, and the display failure with radeon.  Of course it is possible that these are different bugs (but unlikely, since so few pages trigger either one).

Still, this happens only with trunk builds of Firefox (since cairo), so it isn't "just" the driver or the X server.

Comment 9

[Jonathan Baron]

My last comment was wrong.  No resized images work with the radeon driver.  So this may be two bugs after all.

Comment 10

[Dennis Jacobfeuerborn]

See bug 341746 for other strange driver related behavior.

I have switched to the branch builds for now because I don't think there is going to be much progress on any of these image related bugs until someone with more intimate knowledge of Firefox/Cairo/X11/driver integration gets on the case.

Comment 11

[Jonathan Baron]

I've now tried various drivers on two different computers, one using X86_64 linux and one using 32bit.  There are two types of images, call them A and B.  Both involve resizing.
                     A                    B
64bit radeon driver  image replaced       blank image
64bit fglrx driver   X crashes            works
32bit radeon driver  image replaced       blank image?
32bit fglrx driver   image replaced       blank image

"Replaced" means replaced with some part of something seen before. The point is that there is a correlation between the crashing and the replacement of images.  The crash occurs only on 64bit with fglrx.

Comment 12

[Jonathan Baron]

As a result of installing Fedora Core 6, this bug has disappeared, whatever it was, for the ATI drivers.  (I haven't tested Nvidia yet, where I have no found out that it results in no image displayed at all.)  
Possibly, the critical changes were:
kmod-fglrx-8.29.6-1.2.6.18_1.2798.fc6
xorg-x11-drv-fglrx-8.29.6-1.lvn6
(Until these are installed, X does not work at all.)
This is for both x86_64 and i386.
I will test Nvidia in a few days and then perhaps recommend a change to "not a bug," although I do think it had something to do with Cairo too.

Comment 13

[Jonathan Baron]

I have now tested on nvidia, and the bug is fixed there too with Fedora Core 6.  I will attempt to change this to "invalid" even though I do think that it is partly the result of the interaction between cairo and xorg.