This problem is existing before 52.0.2719.0 btw.

Seems to hang at species-ctor.

Reproduced with 
  Version 52.0.2719.0 (64-bit)

Deleted: Screen Shot 2016-04-28 at 6.01.57 PM.png 45.0 KB

	Screen Shot 2016-04-28 at 6.01.57 PM.png 45.0 KB View Download

Thanks, Michael! That reproduces for me too.

I run the test on d8@tot and it doesn't terminate, keeps calling fakeRe.lastIndex.


// Copyright (C) 2015 the V8 project authors. All rights reserved.
/*---
es6id: 21.2.5.11
description: Length coercion of `lastIndex` property of splitter after a match
info: >
    [...]
    24. Repeat, while q < size
        a. Let setStatus be Set(splitter, "lastIndex", q, true).
        [...]
        c. Let z be RegExpExec(splitter, S).
        [...]
        f. Else z is not null,
           i. Let e be ToLength(Get(splitter, "lastIndex")).
           [...]
features: [Symbol.split, Symbol.species]
---*/

var result;
var obj = {
  constructor: function() {}
};
var fakeRe = {
  set lastIndex(_) {},
  get lastIndex() {
    return {
      valueOf: function() {
        return 2.9;
      }
    };
  },
  exec: function() {
    return [];
  }
};
obj.constructor[Symbol.species] = function() {
  return fakeRe;
};

result = RegExp.prototype[Symbol.split].call(obj, 'abcd');

assert(Array.isArray(result));
assert.sameValue(result.length, 2);
assert.sameValue(result[0], '');
assert.sameValue(result[1], 'cd');

The loop in RegExpSubclassSplit never terminates:
https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/js/regexp.js&l=507

The startIndex oscillates between 2 and 3. The size is 4. We just keep adding elements to the array until OOM, so it is not a GC issue.

I bisected the issue to the initial implementation of this regexp function (with --harmony_regexp_exec) : https://codereview.chromium.org/1596483005

Before that commit, the test fails with an error:
TypeError: Method RegExp.prototype.@@split called on incompatible receiver #<constructor>

littledan@, could you please take a look?

machenbach@, since the OOM reproduces in d8, I wonder why our test-262 bots didn't catch it?

"reproduces in d8" with your repro code, or is there a test currently checked in that reproduces this? Is this mac only? We run test262 only in default variant on mac.

reproduces in d8" with your repro code, or is there a test currently checked in that reproduces this?
I took the test from http://v8.github.io/test262/ and reproduces on d8 tot without any local changes.

The correct url is http://v8.github.io/test262/website/default.html#

I didn't check on mac, but I think it should reproduce there too.

Well look at that:
https://code.google.com/p/chromium/codesearch#chromium/src/v8/test/test262/test262.status&l=126

machenbach@, ah that explains it :) Thanks for looking it up.

My reading of the spec is that this is an "expected" infinite loop. The spec (https://tc39.github.io/ecma262/#sec-regexp.prototype-@@split) expects that objects implementing the RegExp "protocol" have reasonable lastIndex get/set behavior.

I filed https://github.com/tc39/test262/issues/613 about this particular test.

Whoops, Mike Pennisi set me straight. Working on a fix.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/96746cc7c7abf85133dd79c889d79a900c46a610

commit 96746cc7c7abf85133dd79c889d79a900c46a610
Author: adamk <adamk@chromium.org>
Date: Mon May 02 17:32:51 2016

Avoid infinite loop in RegExp.prototype[Symbol.split]

Our implementation of the spec got one comparison wrong, at
step 19.d.iii (we were comparing against 'q' instead of 'p').

R=littledan@chromium.org
BUG= chromium:607566 
LOG=n

Review-Url: https://codereview.chromium.org/1940643002
Cr-Commit-Position: refs/heads/master@{#35947}

[modify] https://crrev.com/96746cc7c7abf85133dd79c889d79a900c46a610/src/js/regexp.js
[modify] https://crrev.com/96746cc7c7abf85133dd79c889d79a900c46a610/test/test262/test262.status