If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in Firefox 38

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: gkw, Assigned: djvj)

Tracking

(Blocks: 2 bugs, 4 keywords)

Trunk
mozilla38
x86
Mac OS X
assertion, regression, sec-moderate, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox37 unaffected, firefox38 verified)

Details

(Whiteboard: [fuzzblocker], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
// 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?
Flags: needinfo?(kvijayan)
(Reporter)

Comment 1

3 years ago
Created attachment 8552183 [details]
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)
(Assignee)

Updated

3 years ago
Flags: needinfo?(kvijayan) → needinfo?(mrosenberg)
(Reporter)

Comment 3

3 years ago
Locking as per comment 2 and IRC discussion.
Group: core-security
Keywords: sec-moderate
(Assignee)

Comment 5

3 years ago
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).
(Reporter)

Comment 6

3 years ago
A variant of this crashes js opt 32-bit ARM-simulator shells at JS::ProfilingFrameIterator::extractStack.
Crash Signature: [@ JS::ProfilingFrameIterator::extractStack]
Summary: Assertion failure: stubFrame->prevType() == JitFrame_BaselineJS, at jit/JitFrames.cpp → Crash [@ JS::ProfilingFrameIterator::extractStack] or Assertion failure: stubFrame->prevType() == JitFrame_BaselineJS, at jit/JitFrames.cpp
(Reporter)

Updated

3 years ago
Blocks: 1100132
(Reporter)

Comment 7

3 years ago
This bug is practically making ARM-simulator builds almost unfuzzable due to the constant noise. Setting [fuzzblocker].
Whiteboard: [fuzzblocker]
(Assignee)

Comment 8

3 years ago
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.
Flags: needinfo?(mrosenberg)
(Assignee)

Comment 9

3 years ago
Created attachment 8556667 [details] [diff] [review]
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].
Attachment #8556667 - Flags: review?(luke)

Comment 10

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

Can also drop s-s now?
Attachment #8556667 - Flags: review?(luke) → review+
(Reporter)

Comment 11

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

Opening up.
Group: core-security
(Assignee)

Comment 12

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/2c890016184e
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
(Assignee)

Comment 14

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

Comment 15

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/8197ec54b282
https://hg.mozilla.org/mozilla-central/rev/8197ec54b282
Assignee: nobody → kvijayan
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox38: affected → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Status: RESOLVED → VERIFIED
status-firefox38: fixed → verified
JSBugMon: This bug has been automatically verified fixed.
status-firefox37: --- → unaffected
You need to log in before you can comment on or make changes to this bug.