Arch Linux

Firefox bug at https://bugzilla.mozilla.org/show_bug.cgi?id=892567

Userspace should never be able to crash the kernel. It's invariably a kernel problem.

On github and youtube I've also seen an avatar picture (github) or video thumbnail get incorrectly reused in multiple places or a corrupted picture displayed and these are normally small images.

I have seen corruption in gtk widgets where it draws the rect of a button with a corrupted inner image in various applications but this crash and corrupted jpeg decoding only happens in Firefox.

Same thing happens in Firefox Safe Mode. This is how the corruption in ao2e-index.jpg happens:

* first the image loads completely and is displayed correctly for a split second
* then bottom half of the image is corrupted meaning it doesn't display the original/correct content
* this time around the bottom half actually started to display 3 rectangles or more where there were clearly small snapshots of the whole browser window displayed in the corrupted part's upper half or so

I can fetch a multi-hour talk 720p webm from youtube and view it with various media players utilizing Xv, X11, or OpenGL and I see no picture corruption (except the occasional gtk widget) in Chromium, Opera, PDF viewers etc. So I don't think it's the hardware.

I suspect this is a combination of a bug in the graphics driver and Firefox's threaded image decoding or generally different decoding algorithm compared to Opera and other image viewers.

Didn't try with Aurora or Nightly in Safe Mode because the corruption exists in 22 and I wanted to post this comment first but I'll try 25 next.

Joe Drew suggested to set gfx.xrender.enabled to false and with that restarted so far I haven't been able to see corruption in ao2e-index.jpg. But the fonts were subjectively drawn less sharp or harder to read.

Should I echo the discussion from the Mozilla ticket here or leave it all there?

Did another test with intel-drm's SNA acceleration disabled and gfx.xrender.enabled set to true. No corruption occurred so far as I can see. What could this mean? That the intel driver has a bug with SNA enabled, maybe specifically when driving this chip and not generally? That could be a regression as I am sure that SNA was enabled and used on this machine without such bugs for a long time. Does anyone have experience filing bugs with the Intel guys at freedesktop.org? I'd appreciate help filing this as a regression because with older intel driver versions there were no such problems.

From Xorg.log with SNA:
[ 73.948] (==) Depth 24 pixmap format is 32 bpp
[ 73.948] (II) intel(0): SNA initialized with Alviso (gen3) backend
[ 73.948] (==) intel(0): Backing store disabled
[ 73.948] (==) intel(0): Silken mouse enabled
[ 73.948] (II) intel(0): HW Cursor enabled
[ 73.948] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 73.948] (==) intel(0): DPMS enabled
[ 73.948] (II) intel(0): [XvMC] i915_xvmc driver initialized.
[ 73.948] (II) intel(0): [DRI2] Setup complete
[ 73.948] (II) intel(0): [DRI2] DRI driver: i915
[ 73.948] (II) intel(0): direct rendering: DRI2 Enabled
[ 73.948] (==) intel(0): hotplug detection: "enabled"
[ 73.949] (--) RandR disabled
[ 73.968] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 73.968] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 73.968] (II) AIGLX: enabled GLX_ARB_create_context
[ 73.968] (II) AIGLX: enabled GLX_ARB_create_context_profile
[ 73.968] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile
[ 73.968] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 73.968] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 73.969] (II) AIGLX: Loaded and initialized i915
[ 73.969] (II) GLX: Initialized DRI2 GL provider for screen 0

From Xorg.log without SNA:
[ 4731.653] (==) Depth 24 pixmap format is 32 bpp
[ 4731.653] (II) intel(0): [DRI2] Setup complete
[ 4731.653] (II) intel(0): [DRI2] DRI driver: i915
[ 4731.653] (II) UXA(0): Driver registered support for the following operations:
[ 4731.653] (II) solid
[ 4731.653] (II) copy
[ 4731.653] (II) composite (RENDER acceleration)
[ 4731.654] (II) put_image
[ 4731.654] (II) get_image
[ 4731.654] (==) intel(0): Backing store disabled
[ 4731.654] (==) intel(0): Silken mouse enabled
[ 4731.654] (II) intel(0): Initializing HW Cursor
[ 4731.654] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 4731.654] (==) intel(0): DPMS enabled
[ 4731.654] (==) intel(0): Intel XvMC decoder disabled
[ 4731.654] (II) intel(0): Set up textured video
[ 4731.654] (II) intel(0): Set up overlay video
[ 4731.654] (II) intel(0): direct rendering: DRI2 Enabled
[ 4731.654] (==) intel(0): hotplug detection: "enabled"
[ 4731.683] (--) RandR disabled
[ 4731.703] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 4731.703] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 4731.703] (II) AIGLX: enabled GLX_ARB_create_context
[ 4731.703] (II) AIGLX: enabled GLX_ARB_create_context_profile
[ 4731.703] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile
[ 4731.703] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 4731.703] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 4731.703] (II) AIGLX: Loaded and initialized i915
[ 4731.703] (II) GLX: Initialized DRI2 GL provider for screen 0

Created xorg bug https://bugs.freedesktop.org/show_bug.cgi?id=67209

Does it work if you compile firefox >= 24 with --enable-system-cairo?

I never built Firefox myself. I tested with mozilla.org's binaries and the Arch package also doesn't enable system cairo. Is there a high chance that would solve it? I might be wrong but afaik Firefox uses an old Cairo version internally and I suppose a newer version won't work correctly.

If the xrender option makes a difference, the cairo version probably will too. The latest cairo might not play as nicely with firefox but I would expect it to play more nicely with the latest graphics drivers.

I don't think I can build Firefox with 2GB of RAM can I?

You can if you use -Wl,--no-keep-memory.

A custom Firefox 24.0 with --enable-system-cairo works.

The custom Firefox build doesn't provoke the corruption but as suspected by the Intel devs there are corruption issues just hiding. I don't know if it's related but I've seen a Qt3 application draw text destined for its statusbar outside of the window and right into the X root or over other windows managed by the wm.

I'll keep an eye out for this after enabling UXA.

News: https://bugs.freedesktop.org/show_bug.cgi?id=67209#c27

I don't know when the next xf86-video-intel relase will be so is it a good idea to package a version with that commit in testing?

Image decoding bug looks fixed in xf86-video-intel-2.99.906 but I still have to check the Qt3 out-of-window text drawing/corruption.

Haven't seen Qt3 out-of-window text drawing/corruption either.