Closed Bug 1111245 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: JavaScript Engine: JIT, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla37
Tracking Status
firefox37 --- affected

People

(Reporter: gkw, Assigned: terrence)

References

(Blocks 2 open bugs)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(2 files)

// 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?
Flags: needinfo?(terrence)
Attached file 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)
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.
Flags: needinfo?(terrence)
Assignee: nobody → terrence
Status: NEW → ASSIGNED
Attachment #8538170 - Flags: review?(jorendorff)
Attachment #8538170 - Flags: review?(jorendorff) → review+
https://hg.mozilla.org/mozilla-central/rev/69814624bb02
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.