1132297 - Crash at a weird memory address involving SIMD

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

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

// Randomly chosen test: js/src/jit-test/tests/asm.js/simd-fbirds.js
function asmCompile() {
    f = Function.apply(null, arguments)
}
function asmLink() {
    return f.apply(arguments)
}
m = asmLink(asmCompile('', "\
    function g() {\
        v = SIMD.int32x4(0, 0, 0, 0);\
        (function() {}) | 0\
    }\
    return g\
"), this)
for (var a = 0; a < 4; a++) {
    m()
}

crashes js debug shell on m-c changeset 38058cb42a0e with --fuzzing-safe --no-threads --ion-eager --no-sse4 --ion-gvn=off at a weird memory address.

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-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

python -u ~/fuzzing/js/compileShell.py -b "--enable-debug --enable-optimize --enable-more-deterministic --enable-nspr-build --32 -R ~/trees/mozilla-central" -r 38058cb42a0e

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/ac3b15d06665
user:        Nicolas B. Pierron
date:        Mon Jan 12 16:45:55 2015 +0100
summary:     Bug 1112154 - Add MSimdBox and inline calls to SIMD constructors. r=bbouvier,jandem

Setting s-s because this seems to access a weird memory address. Not sure if this is related to some of the other SIMD bugs found recently.

Nicolas, is bug 1112154 a likely regressor?

Comment 1

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

Process 58865 stopped
* thread #1: tid = 0x321d88, 0x01aae70b, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x01aae70b
-> 0x1aae70b:  movdqa (%esp), %xmm0
   0x1aae710:  addl   $0x10, %esp
   0x1aae713:  cmpl   $0x0, 0x2809e74
   0x1aae71a:  jne    0x1a72480
(lldb) bt
* thread #1: tid = 0x321d88, 0x01aae70b, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x01aae70b
(lldb)

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

Probably a duplicate of bug 1130845.  I've checked with nbp's folded alignment patch, and this test case passes fine with it.

Looking at assembly code, here's an explanation.  Int32x4 ctor codegen does the following:
- spill each lane scalar value (int32) onto the stack, following the layout of a SIMD value.
- load the SIMD value created into the register
This happens with --no-sse4, as when we have sse4, we can use pinsrd, which takes a scalar value and puts it directly in the right lane.

As the Ion frames are not aligned (yet), we have a segfault in the aligned mov here.  Not a security issue (no exploit can be made, it will crash in all builds), but an easy ddos.

Marking as blocked by bug 1112163, I'll take care of closing this bug if it does indeed solve the issue.

Comment 3

[Benjamin Bouvier [:bbouvier] (inactive)]

Fixed by bug 1112160.

Comment 4

[Al Billings [:abillings - ex-MoCo]]

Marking 37 as "disabled" as I don't believe we've shipped SIMD outside of nightlies.