1122993 - Assertion failure: parent->isNative(), at vm/Interpreter.cpp

Status: RESOLVED 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
(function() {
    arguments.__proto__.__proto__ = newGlobal()
})()
// Randomly chosen test: js/src/tests/test262/shell.js
with({}) {
    load("s.js")
}

and s.js is:

function $f(){}
function $f(){}

asserts the following js debug shell on m-c changeset 369a8f14ccf8 with --fuzzing-safe --no-threads --no-ion at Assertion failure: parent->isNative(), at vm/Interpreter.cpp

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-01-17-mozilla-central-debug/jsshell-mac64.zip

This seems to be an ancient bug in the interpreter - setting needinfo? from :Waldo and Eric as a start.

Comment 1

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

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0x1cc8b, 0x0000000100773d52 js-dbg-opt-64-dm-nsprBuild-darwin-369a8f14ccf8`js::DefFunOperation(cx=<unavailable>, script=<unavailable>, scopeChain=<unavailable>, funArg=<unavailable>) + 1762 at Interpreter.cpp:3729, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100773d52 js-dbg-opt-64-dm-nsprBuild-darwin-369a8f14ccf8`js::DefFunOperation(cx=<unavailable>, script=<unavailable>, scopeChain=<unavailable>, funArg=<unavailable>) + 1762 at Interpreter.cpp:3729
    frame #1: 0x000000010076b278 js-dbg-opt-64-dm-nsprBuild-darwin-369a8f14ccf8`Interpret(cx=0x0000000101e02310, state=0x00007fff5fbfd3e8) + 69496 at Interpreter.cpp:3006
    frame #2: 0x000000010075a2e6 js-dbg-opt-64-dm-nsprBuild-darwin-369a8f14ccf8`js::RunScript(cx=0x0000000101e02310, state=0x00007fff5fbfd3e8) + 342 at Interpreter.cpp:448
    frame #3: 0x0000000100770f0a js-dbg-opt-64-dm-nsprBuild-darwin-369a8f14ccf8`js::ExecuteKernel(cx=0x0000000101e02310, scopeChainArg=0x0000000101f77080, thisv=<unavailable>, type=<unavailable>, result=<unavailable>, script=<unavailable>, evalInFrame=<unavailable>) + 970 at Interpreter.cpp:657
    frame #4: 0x0000000100771361 js-dbg-opt-64-dm-nsprBuild-darwin-369a8f14ccf8`js::Execute(cx=0x0000000101e02310, scopeChainArg=<unavailable>, rval=0x0000000000000000, script=<unavailable>) + 449 at Interpreter.cpp:693
(lldb)

Comment 2

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

This was found by combining random js tests together with jsfunfuzz, the specific file(s) is/are:

http://hg.mozilla.org/mozilla-central/file/369a8f14ccf8/js/src/jit-test/tests/basic/bug908915.js
http://hg.mozilla.org/mozilla-central/file/369a8f14ccf8/js/src/tests/test262/shell.js

Comment 3

[Jeff Walden [:Waldo]]

The problem is that load() passes its JS_THIS_OBJECT as the scope chain object for the compiled script.  In the case where it's called with not-its-own-global-object as |this|, the scope chain object is a CCW to the script's global, i.e. a proxy, and things Die, but not so immediately as would obviously be desirable.  :-(  In the example, we're calling a load from another global, using *this* global as this, but this global is not that load's global.  So things eventually die, if someone thinks to check.

A simpler minimization is this:

// file a.js
var otherGlobal = newGlobal();
Object.create(otherGlobal).load("s.js");

// file b.js
function f() {}
function f() {}

As to what to do.  Probably load needs some of the same sort of cross-global treatment that evaluate() appears to have, wrt picking a scope chain object to use.  Arguably it should just use the calling script's global and not look at |this| at all.

This is probably a moderately simple fix, for someone who either understands how to get a scope chain, or who can study the evaluate code enough to grasp the tactics.  But I'm not sure I have the time to do it myself, not for a purely shell-only construct.  Possibly it's mentorable, not sure.

Comment 4

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

The last build I could reproduce this was:

https://archive.mozilla.org/pub/firefox/nightly/2015/03/2015-03-16-mozilla-central-debug/jsshell-linux-x86_64-asan.zip

or:

https://archive.mozilla.org/pub/firefox/nightly/2015/03/2015-03-15-mozilla-central-debug/jsshell-mac64.zip

for non-asan Mac builds.

By 2015-03-17 all builds in:

https://archive.mozilla.org/pub/firefox/nightly/2015/03/2015-03-17-mozilla-central-debug/

likely are unable to reproduce this.

Differences between 2015-03-15 and 2015-03-16:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e19b8b7c8343&tochange=436686833af0

Waldo, did something in this range fix this?

Also, might bug 1052139 be possibly related?

Comment 5

[Jeff Walden [:Waldo]]

Bug 1052139 shouldn't be related, unless I'm not thinking it through hard enough.

At a glance, nothing in that revision range looks like it would have fixed this.  But if I look at annotate history for js/src/shell/js.cpp, I see https://hg.mozilla.org/integration/mozilla-inbound/rev/702b075ca1e6 as very nearly within that date range by its (of course unreliable) timestamp, and doing things that look like they'd have fixed this bug.  So I think bug 1097987 fixed this.