1062258 - xkcd Pixels consumes all gpu memory, crashes system

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Arpad Borsos [:Swatinem]]

The latest xkcd (http://xkcd.com/1416/) seems to exhaust all my gpu memory and lead to my complete system freezing. (only power-cycling can bring it back)

I could reproduce it two times now (don’t really want to crash my system too often).
Just open the page and start scrolling. Firefox itself lags a bit, GCs some.
Then it is killed by the OOM killer and the whole system explodes.

I get some of the following in my journal repeatedly:
Sep 03 13:58:46 swatinux kernel: Xorg.bin invoked oom-killer: gfp_mask=0xa00d2, order=0, oom_score_adj=0
Sep 03 13:58:47 swatinux kernel: Purging GPU memory, 0 bytes freed, 14819328 bytes still pinned.
Sep 03 13:58:47 swatinux kernel: Unable to purge GPU memory due lock contention.

The "purging gpu memory" line is repeated all over. The OOM killer tries to kill one process off after the other. Then I also have a kernel BUG in btrfs:

Sep 03 13:58:47 swatinux kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
Sep 03 13:58:48 swatinux kernel: IP: [<ffffffffa03735aa>] submit_one_bio+0x3a/0xa0 [btrfs]

And all because of xkcd running in firefox :-)

This is running on a sandy bridge laptop with the latest archlinux updates, a fearly recent nightly. OMTC and accelerated layers are OFF.

Comment 1

[Arpad Borsos [:Swatinem]]

I ran some about:memory measurements the second time I was trying it. Nothing unusual. The process itself was chugging along with ~500M.

So it may also be the intel driver that does something wrong here.

mstange said I should need-info you.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

FWIW, I get slowdowns while zooming, but it does not crash for me.  I'm on a beefy win8.1 machine.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Hi Arpad, a few things would help:
* Can you attach the results of about:support (the Graphics section should do)
* I appreciate you not wanting to crash your system often :), but if you could let us know if it also crashes in safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode), it would help.
* Any Firefox crash reports from these crashes?

Comment 4

[Arpad Borsos [:Swatinem]]

(In reply to Milan Sreckovic [:milan] from comment #3)
> * Can you attach the results of about:support (the Graphics section should
> do)

Adapter Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Mobile
Device ID	Mesa DRI Intel(R) Sandybridge Mobile
Driver Version	3.0 Mesa 10.2.6
GPU Accelerated Windows	0/1 Basic
Vendor ID	Intel Open Source Technology Center
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Mobile
windowLayerManagerRemote	false
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

> * I appreciate you not wanting to crash your system often :), but if you
> could let us know if it also crashes in safe mode
> (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode), it would help.

I will do so tomorrow after I have backed up thoroughly and don’t need the machine for production development :-D

> * Any Firefox crash reports from these crashes?

No. Firefox doesn’t really crash itself. It is killed by the OOM killer, which then goes about rendering my complete system unusable.

I’m attaching a dmesg, which contains a few kernel traces and OOM killer output.

Comment 5

[Arpad Borsos [:Swatinem]]

Attachment: dmesg output

Comment 6

[Arpad Borsos [:Swatinem]]

On my windows machine with radeon graphics, it works fine (albeit very laggy).
So the page uses canvas, and according to about:memory allocates a lot of short-lived ArrayBuffers which are collected frequently, and also loads a lot of images which contribute to about memory.

│    │  │  ├───22.05 MB (02.20%) -- image(http://imgs.xkcd.com/turtledown/assembly-4-tiled.png)
│    │  │  │   ├──21.97 MB (02.19%) ── uncompressed-heap

I see heap-unclassified quite high, but once the images are discarded and the GC runs, the heap-unclassified goes down as well.

Comment 7

[Arpad Borsos [:Swatinem]]

Ok, I did some more testing with a fresh nightly (https://hg.mozilla.org/mozilla-central/rev/776fa9cf70cd):

clean profile + safe-mode: oom
clean profile + omtc: oom
clean profile + omtc + skia: fine
(I was zooming / panning around for minutes without a oom / lock up, whereas in the other cases I could create a oom / lock up in ~ half a minute, a few levels into the picture)

In general it took more time to oom now. I suspect its because I’m not running an external screen now. I guess that would constrain the gpu memory a bit more. It also runs a tiny bit smoother.


Turning on skia (+omtc) seems to solve the ooms, so it might be related to cairo/X (ff uses the xlib backend afaik?)
Skia also runs considerably smoother. The smoothness also depends a lot on how many *different* tiles are visible.
Each tile has different mipmap levels encoded in a very inefficiently packed 9600x600 texture. So drawing sub-rects of a lot of those into canvas seems to trigger the gpu oom.

Comment 8

[Gregory Pappas [:gregp]]

Reporter, are you still experiencing this issue?

Comment 9

[Arpad Borsos [:Swatinem]]

Well, this was reported 9 years ago. I don’t even have that old hardware around anymore. So I will just resolve this as INVALID.