guix-devel/gnu/packages/patches/icecat-CVE-2016-1930-pt08.p...

49 lines
1.7 KiB
Diff

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)
{