OOM crash [@ operator new | js::InitJIT | JSCompartment::init]

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: jruderman, Assigned: njn)

Tracking

(Blocks 1 bug, {crash, regression})

Trunk
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: softblocker, crash signature)

Attachments

(1 attachment)

Posted file stack trace
I've heard that OOM is not supposed to crash in the JS engine.

This OOM crash looks like an old bug in js::InitJIT, exposed by making JSCompartment::init call it (in bug 584860).

Gary Kwong found this bug using jsfunfuzz and sent me a non-reduced testcase. I haven't attempted to reduce it.
I guess this is a dup of bug 622291.
Duplicate of this bug: 622291
(In reply to comment #1)
> I guess this is a dup of bug 622291.

Yeah, looks like it.  I'm marking bug 622291 as the dup because it's comments are cluttered.

Bug 623428 should fix the problem, which is that js::InitJIT() has various unchecked allocations.
Hrm. I left a comment there (bug 623428 comment 25).
Depends on: 624878
This should block 2.0, lots of possibilities for crashing on OOM.
blocking2.0: --- → ?
blocking2.0: ? → betaN+
Whiteboard: softblocker
Assignee: general → nnethercote
Bug 624878 just landed on TM, once it lands on m-c we can mark this one as fixed, as it fixed the OOM-crash identified here along with a bunch of others.
Duplicate of this bug: 626046
Per comment 6, bug 624878 just landed on m-c, so this bug is fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Crash Signature: [@ operator new | js::InitJIT | JSCompartment::init]
You need to log in before you can comment on or make changes to this bug.