1113940 - Crash [@ js::HeapSlot::set] or Assertion failure: !(*instructionResults_)[index].isMagic(JS_ION_BAILOUT), at jit/JitFrames.cpp

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

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

gczeal(14);
// Randomly chosen test: js/src/jit-test/tests/basic/bug951213.js
setObjectMetadataCallback(function() {});
// Randomly chosen test: js/src/jit-test/tests/auto-regress/bug691595.js
function f() {
    (function() {
        '' ^ Object
    })();
}
x = 0;
for (var j = 0; j < 99; ++j) {
    x += f();
}

asserts js debug shell on m-c changeset b052018cf239 with --fuzzing-safe --no-threads --ion-eager at Assertion failure: !(*instructionResults_)[index].isMagic(JS_ION_BAILOUT), at jit/JitFrames.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/b052018cf239/js/src/jit-test/tests/basic/bug951213.js
http://hg.mozilla.org/mozilla-central/file/b052018cf239/js/src/jit-test/tests/auto-regress/bug691595.js

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/a50d660f09da
user:        Nicolas B. Pierron
date:        Fri Dec 19 15:28:30 2014 +0100
summary:     Bug 1073033 part 3 - Recover MLambda on bailouts. r=shu

Setting s-s because this seems to involve gczeal(14).

Nicolas, is bug 1073033 a likely regressor?

Comment 1

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

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0x3f756, 0x0000000100318ec1 js-dbg-opt-64-dm-nsprBuild-darwin-b052018cf239`js::jit::SnapshotIterator::fromInstructionResult(unsigned int) const [inlined] JS::Value::isMagic(why=<unavailable>) const + 28 at Value.h:1177, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100318ec1 js-dbg-opt-64-dm-nsprBuild-darwin-b052018cf239`js::jit::SnapshotIterator::fromInstructionResult(unsigned int) const [inlined] JS::Value::isMagic(why=<unavailable>) const + 28 at Value.h:1177
    frame #1: 0x0000000100318ea5 js-dbg-opt-64-dm-nsprBuild-darwin-b052018cf239`js::jit::SnapshotIterator::fromInstructionResult(unsigned int) const [inlined] js::jit::RInstructionResults::operator[](this=<unavailable>, index=<unavailable>, why=<unavailable>) at Value.h:1693
    frame #2: 0x0000000100318ea5 js-dbg-opt-64-dm-nsprBuild-darwin-b052018cf239`js::jit::SnapshotIterator::fromInstructionResult(this=<unavailable>, index=<unavailable>) const + 181 at JitFrames.cpp:2154
    frame #3: 0x000000010031adde js-dbg-opt-64-dm-nsprBuild-darwin-b052018cf239`js::jit::InlineFrameIterator::callee(this=<unavailable>, fallback=0x00007fff5fbfd718) const + 110 at JitFrames.cpp:2405
    frame #4: 0x000000010070de01 js-dbg-opt-64-dm-nsprBuild-darwin-b052018cf239`js::FrameIter::callee(this=<unavailable>, cx=<unavailable>) const + 113 at Stack.cpp:1095
(lldb)

Comment 2

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

This seems to crash 32-bit ARM-simulator builds at js::HeapSlot::set - tested with:

LD=ld CROSS_COMPILE=1 CC="clang -Qunused-arguments -msse2 -mfpmath=sse -arch i386" RANLIB=ranlib CXX="clang++ -Qunused-arguments -msse2 -mfpmath=sse -arch i386" AS=$CC AR=ar STRIP="strip -x -S" HOST_CC="clang -Qunused-arguments -msse2 -mfpmath=sse" AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 HOST_CXX="clang++ -Qunused-arguments -msse2 -mfpmath=sse" sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=i386-apple-darwin9.2.0 --enable-macos-target=10.5 --enable-arm-simulator --enable-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

Comment 3

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

Attachment: Opt stack

(lldb) bt 5
* thread #1: tid = 0x51ee6, 0x003945bb js-dbgDisabled-opt-32-dm-nsprBuild-armSim-darwin-490f124d7dea`js::HeapSlot::set(js::NativeObject*, js::HeapSlot::Kind, unsigned int, JS::Value const&) [inlined] js::gc::StoreBuffer::isEnabled(this=0x7503f883) const at StoreBuffer.h:433, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x75045904)
  * frame #0: 0x003945bb js-dbgDisabled-opt-32-dm-nsprBuild-armSim-darwin-490f124d7dea`js::HeapSlot::set(js::NativeObject*, js::HeapSlot::Kind, unsigned int, JS::Value const&) [inlined] js::gc::StoreBuffer::isEnabled(this=0x7503f883) const at StoreBuffer.h:433
    frame #1: 0x003945bb js-dbgDisabled-opt-32-dm-nsprBuild-armSim-darwin-490f124d7dea`js::HeapSlot::set(js::NativeObject*, js::HeapSlot::Kind, unsigned int, JS::Value const&) [inlined] js::gc::StoreBuffer::isOkayToUseBuffer(this=0x7503f883) const at StoreBuffer.h:367
    frame #2: 0x003945bb js-dbgDisabled-opt-32-dm-nsprBuild-armSim-darwin-490f124d7dea`js::HeapSlot::set(js::NativeObject*, js::HeapSlot::Kind, unsigned int, JS::Value const&) [inlined] void js::gc::StoreBuffer::putFromAnyThread<js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::SlotsEdge>, js::gc::StoreBuffer::SlotsEdge>(this=0x7503f883, buffer=<unavailable>, count=<unavailable>) at StoreBuffer.h:382
    frame #3: 0x003945bb js-dbgDisabled-opt-32-dm-nsprBuild-armSim-darwin-490f124d7dea`js::HeapSlot::set(js::NativeObject*, js::HeapSlot::Kind, unsigned int, JS::Value const&) [inlined] js::gc::StoreBuffer::putSlotFromAnyThread(this=0x7503f883, count=<unavailable>) at StoreBuffer.h:444
    frame #4: 0x003945bb js-dbgDisabled-opt-32-dm-nsprBuild-armSim-darwin-490f124d7dea`js::HeapSlot::set(js::NativeObject*, js::HeapSlot::Kind, unsigned int, JS::Value const&) [inlined] js::HeapSlot::post(this=<unavailable>, target=0xffffff88) + 21 at Barrier.h:905
(lldb)

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to Gary Kwong [:gkw] [:nth10sd] GMT+8 Dec 12 - 22 from comment #0)
> Nicolas, is bug 1073033 a likely regressor?

Yes, I will investigate, keeping the ni? in the mean time.

Comment 6

[Nicolas B. Pierron [:nbp]]

Ok, the problem is that the ShellObjectMetadataCallback is looking for the callee of the function.  The problem is that the bailout happens within the lambda which was not allocated, and as such when we reconstruct the Lambda, we call the metadata callback which query the callee.

Initially the lambda was supposed to be allocated in the context of the function which hold its scope chain.  So, either we can make this information flow into the Metadata callback, or we should just skip the metadata callback as we used to do for other recover instruction allocation previously.

Comment 7

[Nicolas B. Pierron [:nbp]]

Attachment: Disable the object metadata callback in order to avoid recover instructions re-entry.

This patch basically revert what was done in Bug 1083781 for each recover
instruction, except that now, we wrap this in the caller of these recover
functions.

With Bug 1073033, it is no longer safe to iterate the stack anymore as we
might have to reconstruct a callee (a lambda) that we are currently
allocating.

Comment 8

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8540197 [details] [diff] [review]
Disable the object metadata callback in order to avoid recover instructions re-entry.

Review of attachment 8540197 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jit-test/tests/ion/recover-lambdas-bug1113940.js
@@ +1,1 @@
> +

fixed: I've added Bug 1114571 test case as well, both are fixed by this patch.

Comment 9

[Nicolas B. Pierron [:nbp]]

(try) https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=ac7db99e8995
(inbound) https://hg.mozilla.org/integration/mozilla-inbound/rev/7f84fe59708a

Comment 10

[Andrew McCreight [:mccr8]]

The object metadata callback isn't something that we'd normally run, right?  Can this bug be unhidden?

Comment 11

[Nicolas B. Pierron [:nbp]]

(In reply to Andrew McCreight [:mccr8] (away-ish Dec 17-26) from comment #10)
> The object metadata callback isn't something that we'd normally run, right? 
> Can this bug be unhidden?

The object metadata callback is a hook for the debugger.  So indeed, we'd not normally run it, but the dev-tools will.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7f84fe59708a

Comment 13

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.