1124036 - Crash [@ JS::ProfilingFrameIterator::extractStack] or Assertion failure: stubFrame->prevType() == JitFrame_BaselineJS, at jit/JitFrames.cpp

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

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

// Randomly chosen test: js/src/jit-test/tests/basic/bug908915.js
enableSPSProfilingWithSlowAssertions();
enableSingleStepProfiling();
(function() {
    arguments.__proto__.__proto__ = newGlobal()
    function f(y) {
        y()
    }
    for each(b in []) {
        if (b.name == "arrayInfo" ||
            b.name == "cacheEntry"||
            b.name == "cloneAndExecuteScript" ||
            b.name == "compile" ||
            b.name == "countHeap" ||
            b.name == "createMappedArrayBuffer" ||
            b.name == "dateNow" ||
            b.name == "decompileBody" ||
            b.name == "decompileFunction" ||
            b.name == "decompileThis" ||
            b.name == "deserialize" ||
            b.name == "deterministicgc" ||
            b.name == "disableSPSProfiling")
        try {
            f(b)
        } catch (e) {}
    }
})();

asserts js debug 32-bit ARM-simulator shell on m-c changeset c2df1daf74c3 with --fuzzing-safe --no-threads --no-ion at Assertion failure: stubFrame->prevType() == JitFrame_BaselineJS, at jit/JitFrames.cpp

Debug configure options:

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/70a8168c7d24
user:        Kannan Vijayan
date:        Thu Jan 15 20:11:21 2015 -0500
summary:     Bug 1057082 - 3/7 - Modify jits to use lastProfilingFrame and lastProfilingCallSite fields. r=jandem

Kannan, is bug 1057082 a likely regressor?

Comment 1

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

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0xa1fab, 0x00399ff7 js-dbg-opt-32-dm-nsprBuild-armSim-darwin-c2df1daf74c3`js::jit::JitProfilingFrameIterator::operator++(this=<unavailable>) + 471 at JitFrames.cpp:2948, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00399ff7 js-dbg-opt-32-dm-nsprBuild-armSim-darwin-c2df1daf74c3`js::jit::JitProfilingFrameIterator::operator++(this=<unavailable>) + 471 at JitFrames.cpp:2948
    frame #1: 0x007de791 js-dbg-opt-32-dm-nsprBuild-armSim-darwin-c2df1daf74c3`JS::ProfilingFrameIterator::operator++(this=0xbfffe558) + 81 at Stack.cpp:1768
    frame #2: 0x00016891 js-dbg-opt-32-dm-nsprBuild-armSim-darwin-c2df1daf74c3`SingleStepCallback(arg=0x02041400, sim=0x0280a800, pc=0x019e6534) + 401 at js.cpp:4164
    frame #3: 0x0052f18e js-dbg-opt-32-dm-nsprBuild-armSim-darwin-c2df1daf74c3`void js::jit::Simulator::execute<false>(this=0x0280a800) + 126 at Simulator-arm.cpp:4215
    frame #4: 0x005191c7 js-dbg-opt-32-dm-nsprBuild-armSim-darwin-c2df1daf74c3`js::jit::Simulator::callInternal(this=0x0280a800, entry=0x019db948) + 231 at Simulator-arm.cpp:4305
(lldb)

Comment 3

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

Locking as per comment 2 and IRC discussion.

Comment 5

[Kannan Vijayan [:djvj]]

Not sure where it's happening, but it should be pretty easy to find since it should be happening shortly before it's caught by the assertion.  This is because the stack walk is being done at every ARM instruction boundary, so the first instruction executed by the simulator after the corruption will catch the issue.

To discover the issue, I added instrumentation to the ICCallScriptedCompiler stub generator, to pause immediately after the "enterStubFrame()" call, dumped the stack at that location, and then dumped the stack again later when the assertion hit.  Here are the two stacks:

When stub-frame is entered for the first time:
(gdb) x/40wx 0xf69feeb0
0xf69feeb0:     0xf69fef2c      0x095078a0      0xf7a606bc      0x00000701
0xf69feec0:     0xf6645190      0xffffff88      0x00000000      0xffffff82
0xf69feed0:     0xf6652e00      0xffffff88      0xf6645190      0xffffff88
0xf69feee0:     0xf6652de0      0xffffff88      0xf667e060      0xffffff88
0xf69feef0:     0xf664a820      0xffffff88      0xf6652e00      0xffffff88
0xf69fef00:     0x00000000      0x00000000      0x00000000      0x00000000
0xf69fef10:     0x00000070      0xf6644040      0x00000000      0xf664a820
0xf69fef20:     0x00000000      0x00000000      0x00000010      0xf69fef48
0xf69fef30:     0xf7a549b8      0x00000183      0xf6652da0      0x00000000
0xf69fef40:     0x00000000      0xffffff82      0x0000233d      0x00000000

At time of ASSERT:
(gdb) x/40wx 0xf69feeb0
0xf69feeb0:     0xf69fef2c      0x095078a0      0xf7a606bc      0xffffff82
0xf69feec0:     0xf6645190      0xffffff88      0x00000000      0xffffff82
0xf69feed0:     0xf6652e00      0xffffff88      0xf6645190      0xffffff88
0xf69feee0:     0xf6652de0      0xffffff88      0xf667e060      0xffffff88
0xf69feef0:     0xf664a820      0xffffff88      0xf6652e00      0xffffff88
0xf69fef00:     0x00000000      0x00000000      0x00000000      0x00000000
0xf69fef10:     0x00000070      0xf6644040      0x00000000      0xf664a820
0xf69fef20:     0x00000000      0x00000000      0x00000010      0xf69fef48
0xf69fef30:     0xf7a549b8      0x00000183      0xf6652da0      0x00000000
0xf69fef40:     0x00000000      0xffffff82      0x0000233d      0x00000000

Note that the last word on the first row goes from 0x00000701 to 0xffffff82.  The stack otherwise stays the same.

The profiler patches I added don't do any stack mutation, aside from writes to JitActivation things (which in this example, won't be on the simulator stack).

Comment 6

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

A variant of this crashes js opt 32-bit ARM-simulator shells at JS::ProfilingFrameIterator::extractStack.

Comment 7

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

This bug is practically making ARM-simulator builds almost unfuzzable due to the constant noise. Setting [fuzzblocker].

Comment 8

[Kannan Vijayan [:djvj]]

Ok, I think I know what's going on here, and it's not a real bug.

Basically, one of the functions in the list is disableSPSProfiling.  After it gets called, profiling gets disabled.. but single-stepping is still enabled.. but single-stepping uses the profiling iterator, which gets all screwed up because profiling is turned off and the lastProfilingFrame is no longer being maintained.

Comment 9

[Kannan Vijayan [:djvj]]

Attachment: fix-bug-1124036.patch

Fix is just to have single-stepping callback check spsProfiler, and no-op if it's not enabled.  That way, the fuzzer doesn't have to worry about carefully sequencing calls to [enable|disable][SingleStepping|SPSProfiling].

Comment 10

[Luke Wagner [:luke]]

Comment on attachment 8556667 [details] [diff] [review]
fix-bug-1124036.patch

Can also drop s-s now?

Comment 11

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

(In reply to Luke Wagner [:luke] from comment #10)
> Can also drop s-s now?

Opening up.

Comment 12

[Kannan Vijayan [:djvj]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2c890016184e

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Backed out for SM(arm) failures. Please verify that this at least passes locally (bonus points for Try) before pushing again.
https://hg.mozilla.org/integration/mozilla-inbound/rev/60c3e5d5190e

https://treeherder.mozilla.org/logviewer.html#?job_id=6106318&repo=mozilla-inbound

Comment 14

[Kannan Vijayan [:djvj]]

Ok fixed up patch try run looks good for SM now: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1f41147f9127

Comment 15

[Kannan Vijayan [:djvj]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8197ec54b282

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8197ec54b282

Comment 17

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.