blob: 406ce1bf2bcb66fae75da4b018d8ddc6b05c306c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
Copied from: https://hg.mozilla.org/releases/mozilla-esr38/rev/4444e94a99cb
Security advisory: https://www.mozilla.org/en-US/security/advisories/mfsa2016-01/
Mozilla Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1221385
# HG changeset patch
# User Jan de Mooij <jdemooij@mozilla.com>
# Date 1451478429 -3600
# Node ID 4444e94a99cb9b00c0351cc8bf5459739cc036a5
# Parent 750e4cfc90f80df657e44c9c63b1865023d88682
Bug 1221385 - Handle OOM during JitRuntime initialization a bit better. r=bhackett a=abillings
diff --git a/js/src/jscompartment.cpp b/js/src/jscompartment.cpp
--- a/js/src/jscompartment.cpp
+++ b/js/src/jscompartment.cpp
@@ -138,28 +138,20 @@ JSRuntime::createJitRuntime(JSContext* c
// Protect jitRuntime_ from being observed (by InterruptRunningJitCode)
// while it is being initialized. Unfortunately, initialization depends on
// jitRuntime_ being non-null, so we can't just wait to assign jitRuntime_.
JitRuntime::AutoMutateBackedges amb(jrt);
jitRuntime_ = jrt;
if (!jitRuntime_->initialize(cx)) {
- js_ReportOutOfMemory(cx);
-
- js_delete(jitRuntime_);
- jitRuntime_ = nullptr;
-
- JSCompartment* comp = cx->runtime()->atomsCompartment();
- if (comp->jitCompartment_) {
- js_delete(comp->jitCompartment_);
- comp->jitCompartment_ = nullptr;
- }
-
- return nullptr;
+ // Handling OOM here is complicated: if we delete jitRuntime_ now, we
+ // will destroy the ExecutableAllocator, even though there may still be
+ // JitCode instances holding references to ExecutablePools.
+ CrashAtUnhandlableOOM("OOM in createJitRuntime");
}
return jitRuntime_;
}
bool
JSCompartment::ensureJitCompartmentExists(JSContext* cx)
{
|
