745514 - viewing large png image in firefox crashes Xserver

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[jippie]

Attachment: Created using bootchart 0.90.2-8ubuntu1 and pybootchartgui 0+r141-0ubuntu3

I created a PNG image using bootchart and I tried to view it in Firefox. Loading took 2 maybe 3 seconds, during load the entire Xserver crashes and desktop session restarts.

Reproducable, every time I try to load the image in Firefox my Xsession crashes. ImageMagick's display and gwenview display the image fine.

System: Kubuntu 11.10, fully patched until 14-4-2012. Not sure if the problem existed before.

Potentially DoS if such an image is hosted on a website, therefore marked as security problem.

Comment 1

[jippie]

Attachment: X server log for a short desktop session that crashes when the image is opened.

Comment 2

[Al Billings [:abillings - ex-MoCo]]

What version of Firefox were you using?

Comment 3

[jippie]

The short answer is 11.0

firefox                    11.0+build1-0ubuntu0.11.10.1 
firefox-globalmenu         11.0+build1-0ubuntu0.11.10.1 
firefox-kde-support        0.6.2-0ubuntu2
kubuntu-firefox-installer  11.10ubuntu1 
xul-ext-ubufox             1.0.3-0ubuntu1

Comment 4

[Joe Drew (not getting mail)]

This feels a lot like a dupe, but I can't find one. In short, this is probably a driver bug caused by our image optimization (uploading directly to the X server). You can work around it by setting MOZ_DISABLE_IMAGE_OPTIMIZE to 1 in your environment.

Comment 5

[Karl Tomlinson (:karlt)]

> [ 33838.347] 3: /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x7fc6a9c4b000+0x43b30) [0x7fc6a9c8eb30]
> [ 33838.347] 4: /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x7fc6a9c4b000+0x3f406) [0x7fc6a9c8a406]
> [ 33838.347] 5: /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x7fc6a9c4b000+0x30f2b) [0x7fc6a9c7bf2b]

If you are able to install the debuginfo packages for (lib)pixman, then addr2line may provide some more clues. something like

> addr2line -if -e /usr/lib/debug/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.24.4.debug 0x43b30

but this looks like a bug in pixman or xorg-server or maybe xf86-video-intel.
I haven't managed to reproduce when using fb drivers.

Comment 6

[jippie]

I know may way around on Linux, but I'm far from a C++ developer/troubleshooter. That being said, please bear with me trying my best to give useful information.

I installed the following package:
> libpixman-1-0-dbg - pixel-manipulation library for X and cairo (debugging symbols)

Notice the filename is different from what you proposed:
> $ laddr2line -if -e /usr/lib/debug/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.22.2 0x43b30
> bits_image_fetch_bilinear_affine
> /build/buildd/pixman-0.22.2/build/pixman/../../pixman/pixman-bits-image.c:824
> bits_image_fetch_bilinear_affine_pad_x8r8g8b8
> /build/buildd/pixman-0.22.2/build/pixman/../../pixman/pixman-bits-image.c:1042

Comment 7

[Karl Tomlinson (:karlt)]

Yes, that's right, but that info doesn't really narrow down the cause much.

I'd suggest filing a bug against xf86-video-intel, as a best guess.

Comment 8

[jippie]

I see I skipped two lines in my answer:

> $ addr2line -if -e /usr/lib/debug/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.22.2 0x3f406
> src_get_scanline_narrow
> /build/buildd/pixman-0.22.2/build/pixman/../../pixman/pixman-bits-image.c:1352

> $ addr2line -if -e /usr/lib/debug/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.22.2 0x30f2b
> general_composite_rect
> /build/buildd/pixman-0.22.2/build/pixman/../../pixman/pixman-general.c:208


Are you sure you mean 'xf86-video-intel'? I don't see such a module being loaded in Xorg.0.log. Shouldn't it exist as a file on my PC?

Comment 9

[Karl Tomlinson (:karlt)]

The associated file is /usr/lib/xorg/modules/drivers/intel_drv.so.
Some distributions may give the package a different name.

Comment 10

[Stewart]

I am also seeing this bug, for JPG images.
(Based on the similarity, I'm posting here instead of filing a new bug report)
My system is i686 Sempron, NVidia card, Debian-8.2 nouveau driver. (Not intel driver as reported above.)

When browsing the web, my X server crashed and I was dumped out to the login screen. After having it happen to more than one file, I started investigating whether or not the page or the image was infected.
I narrowed it down to the image, and after proving I can load and view the image without problem in gimp, feh, and ristretto; I saved a couple images in gimp and found they too crashed my X session when loaded in newer browsers Iceweasel-38.2 and current Iceweasel-38.4 and Seamonkey-2.33. The crash does not occur with older browser Seamonkey-1.1.

http://seahorseCorral.org/images/tests/4356-BadCrashes-export2.jpg

Comment 11

[Stewart]

Attachment: X server log for the crash when jpg image is opened.

Comment 12

[fr]

It also happens when opening https://de.wikipedia.org/wiki/Venezuela on UltraHD in fullscreen, only on Linux (Mint 17.3 x64 in this case). Single/dual head is not the problem, on Windows, things are fine as well. Memory should not be the problem either (12 GB, just checked). On Chromium/Linux, there is also no problem...

Comment 13

[fr]

(In reply to rudolphi from comment #12)
> It also happens when opening https://de.wikipedia.org/wiki/Venezuela on
> UltraHD in fullscreen, only on Linux (Mint 17.3 x64 in this case).
> Single/dual head is not the problem, on Windows, things are fine as well.
> Memory should not be the problem either (12 GB, just checked). On
> Chromium/Linux, there is also no problem...

In FF43, the first click is ok, but when going back and clicking again, it still crashes the Xserver. Then, the problematic page will try to display again on startup, and you have to fiddle it away, as not even the "Oops,..." page is displayed on fresh startup, but rather the previous set of tabs tries to load :-(

Comment 14

[Tracy Walker [:tracy]]

works for me with default theme on Ubuntu 16.04 with Nightly 51.0a1, 20160823030224

Comment 15

[Stewart]

works for me now. I'll assume it was resolved in one of the debian package security fixes.