1111245 - Assertion failure: maybecx->runtime()->hadOutOfMemory, at jscntxt.cpp

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

// Randomly chosen test: js/src/tests/ecma_2/Exceptions/exception-005.js
// -- reduced away --
// Randomly chosen test: js/src/jit-test/tests/basic/bug858097.js
gcparam("maxBytes", gcparam("gcBytes"));
// Randomly chosen test: js/src/jit-test/tests/gc/bug-906243.js
x = []
Object.defineProperty(x, 0, {
    set: function() {}
})
for (var y = 0; y < 99; ++y) {
    Array.prototype.unshift.call(x, function() {})
}

asserts js debug shell on m-c changeset 5288b15d22de with --fuzzing-safe --no-threads --ion-eager at Assertion failure: maybecx->runtime()->hadOutOfMemory, at jscntxt.cpp.

Debug configure options:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

This was found by combining random js tests together with jsfunfuzz, the specific file(s) is/are:

http://hg.mozilla.org/mozilla-central/file/5288b15d22de/js/src/tests/ecma_2/Exceptions/exception-005.js
http://hg.mozilla.org/mozilla-central/file/5288b15d22de/js/src/jit-test/tests/basic/bug858097.js
http://hg.mozilla.org/mozilla-central/file/5288b15d22de/js/src/jit-test/tests/gc/bug-906243.js

This also asserts js shells from FTP at:

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-12-11-mozilla-central-debug/jsshell-mac64.zip

Since this seems to be a GC/OOM bug, the bisection(s) I ran did not make sense.

Terrence, any idea what's going on here?

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0x1dafea, 0x00000001004b9cf0 js-dbg-opt-64-dm-nsprBuild-darwin-5288b15d22de`js::ThreadSafeContext::recoverFromOutOfMemory(this=<unavailable>) + 224 at jscntxt.cpp:1003, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001004b9cf0 js-dbg-opt-64-dm-nsprBuild-darwin-5288b15d22de`js::ThreadSafeContext::recoverFromOutOfMemory(this=<unavailable>) + 224 at jscntxt.cpp:1003
    frame #1: 0x00000001006ad396 js-dbg-opt-64-dm-nsprBuild-darwin-5288b15d22de`js::Shape::search(cx=<unavailable>, start=0x0000000101f76b50, pspp=<unavailable>, adding=<unavailable>, id=<unavailable>) + 278 at Shape-inl.h:137
    frame #2: 0x0000000100654066 js-dbg-opt-64-dm-nsprBuild-darwin-5288b15d22de`js::NativeObject::lookup(this=<unavailable>, cx=0x0000000101c14af0, id=<unavailable>) + 54 at NativeObject.cpp:284
    frame #3: 0x000000010067f782 js-dbg-opt-64-dm-nsprBuild-darwin-5288b15d22de`bool js::LookupOwnPropertyInline<(cx=0x0000000101c14af0, donep=0x00007fff5fbfea37, obj=<unavailable>, id=<unavailable>, objp=<unavailable>, propp=<unavailable>)1>(js::ExclusiveContext*, js::MaybeRooted<js::NativeObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<jsid, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::MutableHandleType, js::MaybeRooted<js::Shape*, (js::AllowGC)1>::MutableHandleType, bool*) + 290 at NativeObject-inl.h:531
    frame #4: 0x000000010067ba56 js-dbg-opt-64-dm-nsprBuild-darwin-5288b15d22de`bool js::LookupPropertyInline<(cx=0x0000000101c14af0, obj=<unavailable>, id=<unavailable>, objp=<unavailable>, propp=<unavailable>)1>(js::ExclusiveContext*, js::MaybeRooted<js::NativeObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<jsid, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::MutableHandleType, js::MaybeRooted<js::Shape*, (js::AllowGC)1>::MutableHandleType) + 86 at NativeObject-inl.h:595
(lldb)

Comment 2

[Terrence Cole [:terrence]]

Shape::hashify is calling ensureOwnBaseShape; which is calling js_NewGCBaseShape<NoGC>; since we're out of memory we fail the alloc; but since we're NoGC, we cannot run a GC to free up memory; we thus return false without setting an OOM error as we're not sure if we're OOM yet. In this case, it is the caller's responsibility to handle the OOM. But looking further, the behavior of ReportOutOfMemory and recoverFromOutOfMemory is nonsensical in many cases. So I think we want to hurry up with the static analysis and just delete the nonsensical bits in the meantime. They're basically only serving to give us nonsensical fuzz bugs like this at the moment. I'll get a patch up to do that shortly.

Comment 3

[Terrence Cole [:terrence]]

Attachment: bug-1111245-v0.diff

Comment 4

[Terrence Cole [:terrence]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/69814624bb02

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/69814624bb02