636356 - WebGL crash [@mozilla::WebGLBuffer::ZeroDataIfElementArray]

Status: VERIFIED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Christoph Diehl [:posidron]]

Attachment: testcase

Build identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110223 Firefox/4.0b13pre
OpenGL vendor ('Tungsten Graphics, Inc') unrecognized

$ uname -r
2.6.35-24-generic-pae

$ lspci -v
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 040e
	Flags: bus master, fast devsel, latency 0, IRQ 43
	Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3050 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
	Kernel modules: i915

$ modinfo i915
filename:       /lib/modules/2.6.35-24-generic-pae/kernel/drivers/gpu/drm/i915/i915.ko
license:        GPL and additional rights
description:    Intel Graphics
author:         Tungsten Graphics, Inc.
license:        GPL and additional rights
srcversion:     D34C2E6E5CC7885CFC640FC
depends:        drm,drm_kms_helper,video,intel-agp,i2c-algo-bit
vermagic:       2.6.35-24-generic-pae SMP mod_unload modversions 686

Comment 1

[Christoph Diehl [:posidron]]

Attachment: callstack

Comment 2

[Christoph Diehl [:posidron]]

This graphic card is normally on the blacklist, but I wanted to test my fuzzer on a Linux box and I only have one. Perhaps this bug is also reproducible in other (Linux) environments.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Woohoo, this test case does bring my computer down to a crawl. Investigating.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

So, what this testcase does is allocate a buffer of 2G and memset it (initialized it by zeros).

For me, the first time this runs fine; the second time it brings my computer down to a crawl because the first webgl context has not yet been GC'd, so we now have 4G around.

There doesn't seem to be anything WebGL specific here. You can kill any computer with slow on-disk virtual memory by allocating very large arrays; you can do that in plain Javascript.

But you were reporting a crash. What's that? The call stack that you attach doesn't refer to a specific error (such as 'invalid read').

Comment 5

[Christoph Diehl [:posidron]]

edi is null

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

Oh. Now I get it. The realloc() call failed, returned null, and the subsequent memset() crashes.

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: handle out-of-memory

Trivial fix checking for realloc returning NULL; took this occasion to introduce ErrorOutOfMemory helper and use it in a couple of other places.

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/mozilla-central/rev/0406b7cc083e

Comment 9

[Alex Lakatos[:AlexLakatos]]

Verified on Build identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0