Closed Bug 636356 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: Canvas: WebGL, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: posidron, Assigned: bjacob)

References

(Blocks 1 open bug)

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(3 files)

Attached file 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
Attached file callstack
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.
Woohoo, this test case does bring my computer down to a crawl. Investigating.
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').
edi is null
Oh. Now I get it. The realloc() call failed, returned null, and the subsequent memset() crashes.
Trivial fix checking for realloc returning NULL; took this occasion to introduce ErrorOutOfMemory helper and use it in a couple of other places.
Attachment #514810 - Flags: review?(jmuizelaar)
Attachment #514810 - Flags: review?(jmuizelaar) → review+
Attachment #514810 - Flags: approval2.0+
http://hg.mozilla.org/mozilla-central/rev/0406b7cc083e
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Verified on Build identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED
Blocks: 658170
Crash Signature: [@mozilla::WebGLBuffer::ZeroDataIfElementArray]
Assignee: nobody → bjacob
You need to log in before you can comment on or make changes to this bug.