[builtins] adapt arguments for Builtins::kIteratorPrototypeIterator

test/mjsunit/es6/regress/regress-650172.js

Index: test/mjsunit/es6/regress/regress-650172.js
diff --git a/test/message/generators-throw1.js b/test/mjsunit/es6/regress/regress-650172.js
similarity index 59%
copy from test/message/generators-throw1.js
copy to test/mjsunit/es6/regress/regress-650172.js
index b4d404a1bf4d1e8f46c669c79f9ececd6f1ee64f..1b7d30a7ee34a058bc2ade566c2821f445abfc6b 100644
--- a/test/message/generators-throw1.js
+++ b/test/mjsunit/es6/regress/regress-650172.js
@@ -2,6 +2,7 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
-function* f() { yield }
+// Flags: --ignition

[Benedikt Meurer, 2016/09/26 18:30:31]

Does it also repro with --ignition-staging? If so, then you don't need the
Flags: here.

[caitp, 2016/09/26 21:51:47]

It does if the division is there to cause the x87 PF (might not crash on other
architectures though). Ignition crashes in more more cross-platform ways,
including CHECK failures when tracing is enabled when this kind of bug occurs.

But alright, I can live with that. sgtm

[Benedikt Meurer, 2016/09/27 03:33:24]

Please nuke the Flags: if it also crashes with --ignition-staging. The reason
behind this is that we want to nuke the --ignition flag in favour of
--ignition-staging (plus --turbo).

[caitp, 2016/09/27 09:09:03]

So, you're saying you'd prefer `Flags: --ignition-staging --turbo`? Or, just no
flags? "nuke the Flags:" is telling me the latter, and "nuke --ignition in
favour of --ignition-staging" is telling me the former.

[Benedikt Meurer, 2016/09/27 09:14:29]

Sorry for the confusion: We run --ignition-staging as part of the bot defaults,
which means you don't need to include it here explicitly in Flags:. So if it
crashes with --ignition-staging, then remove the Flags: line. If it only crashes
with --ignition, then keep the Flags: line.

[caitp, 2016/09/27 09:18:23]

I see, done.

 
-f().throw(42);
+var iterator = [].entries().__proto__.__proto__[Symbol.iterator];

[Benedikt Meurer, 2016/09/26 18:30:31]

How about using Array.prototype[Symbol.iterator].__proto__ instead? that should
be the same.

[caitp, 2016/09/26 21:51:47]

SGTM

[caitp, 2016/09/26 22:12:52]

Actually, doing that doesn't hit the crash.

[].entries() -> instantiates ArrayIterator
ArrayIterator.__proto__ -> instance of %ArrayIteratorPrototype%
%IteratorPrototype%.__proto__-> instance of %IteratorPrototype%

vs

Array -> %Array%
Array.prototype -> %ArrayPrototype%
Array.prototype[Symbol.iterator] -> %ArrayProto_values%
%ArrayProto_values%.__proto__ -> %FunctionPrototype%
%ArrayProto_values%.prototype -> undefined

So, you need to get at %IteratorPrototype% via an instance of the iterator.

[Benedikt Meurer, 2016/09/27 03:33:24]

Acknowledged.

+print(1/iterator(-1E-300));

[Benedikt Meurer, 2016/09/26 18:30:31]

I guess you don't need the print or the division, please remove that.

[caitp, 2016/09/26 21:51:47]

well, the division causes an x87 PF (because not enough values on the ST regs,
because iterator() doesn't clean up its stack, because no arguments adaptor
frame) --- so the division makes the bug clear (and makes it easier to crash).

The print() is mostly for debugging the test, but it doesn't really impact built
bots or manusal testing, so I think it's not too bad. I'll remove it it if you
want though)

[Benedikt Meurer, 2016/09/27 03:33:24]

Acknowledged.