In 54.0.2817.1 the behaviour has changed. Pressing TAB no longer triggers a crash. But playing around with the emulator's overlay UI (browse the menu, open windows) will *freeze* the page now (instead of aw-snap).

This is similar behaviour to the older bug in the same demo: https://bugs.chromium.org/p/chromium/issues/detail?id=611976

I can repro this on my MAC too. Andreas PTAL

I can repro this on Linux with Chrome/54.0.2824.0

+epertoso

Hi Jaro,

Could you take a look at this?

Could this CL: https://codereview.chromium.org/2145683004 be the cause of this problem. I noticed that if you revert this CL in chromium 54.0.2797, then the webpage does not crash anymore. The error message back then was

#
# Fatal error in ../../v8/src/compiler/representation-change.cc, line 784
# RepresentationChangerError: node #13839:Phi of kMachNone (None) cannot be changed to kRepFloat32
#
	
This crash happened immediately at startup.

The crash looks differently in 54.0.2830 because you have to wait for the page to load completely and then press tab. However, it could be the case that newer changes only cover the original problem.

Reverting the CL https://codereview.chromium.org/2145683004 in ToT would fix the problem.

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

commit b190d13331ba454a416e03c63804f1873252b24f
Author: jarin <jarin@chromium.org>
Date: Wed Aug 17 08:45:02 2016

[turbofan] Only do value numbering when types are compatible.

At the moment, two NumberConstant nodes get different type even if their
value is the same because we always allocate a new heap number for
each number constant. This can lead to replacing a node with a node of
disjoint type in value numbering, which can result in incorrect code
down the line because of inconsistent types.

This fix makes sure that we only replace a node with a sub-type
node. Once we introduce a proper type for number constants, we can
move back to the intersection typing in value numbering.

Unfortunately, it is quite hard to write a repro for this because we cache NumberConstant nodes. We only throw away cached values that have too many conflicts (>5), so the test has to contain values that fall into the same bucket. That's where the magic floating point numbers in the test come from (they have the same low 8-bits of their hashes).

BUG= chromium:633497 

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

[modify] https://crrev.com/b190d13331ba454a416e03c63804f1873252b24f/src/compiler/value-numbering-reducer.cc
[add] https://crrev.com/b190d13331ba454a416e03c63804f1873252b24f/test/mjsunit/compiler/regress-633497.js

Looks like I'm not able to reproduce the problem anymore in Canary Version 54.0.2835.0 canary (64-bit) on OSX 10.12 beta 5.