970277 - Assertion failure: activation->isInterpreter(), at vm/Stack.cpp:554 or Crash [@ script] or Crash [@ js::NonBuiltinScriptFrameIter::settle] or Crash [@ operator++] with setObjectMetadataCallback

Status: RESOLVED DUPLICATE of bug 971385

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision ecf20a2484b6 (threadsafe build, run with --fuzzing-safe --ion-eager):


setObjectMetadataCallback(true);
var arr = ["a", "b", "c", "d", "e", "f", "g", "h"];
assertArraySeqParResultsEq(arr, "map", function(e) {});
function assertArraySeqParResultsEq(arr, op, func) {
  function f() {
     return arr[op + "Par"].apply(arr, [func, null]); 
  }
  while (true) f();
}

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Christian Holler (:decoder)]

It is possible that this is a shell-only crash, but because the crashes show non-null addresses and switch randomly (probably due to threading), I'm marking this s-s until triaged.

Comment 3

[Daniel Veditz [:dveditz]]

Is there a regression range on this?

Comment 4

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/ad7777f1c0f5
user:        Shu-yu Guo
date:        Fri Feb 07 14:40:29 2014 -0800
summary:     Bug 958370 - Unify chunks and slices; self-host the scheduler's slice processing loop. (r=nmatsakis)

Shu-yu, is bug 958370 a likely regressor?

Comment 5

[Shu-yu Guo [:shu]]

This is a dup of bug 971385, but that one is open. Should we close that one and mark dup?

Comment 6

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

(In reply to Shu-yu Guo [:shu] from comment #5)
> This is a dup of bug 971385, but that one is open. Should we close that one
> and mark dup?

I'm not sure, in any case the testcases weren't immediately obvious (setObjectMetadataCallback here vs buildPar there).

If this issue is bad, we should lock the other bug and dupe bugs to whichever has the fix.