Sample testcase for repro is available in - https://github.com/primefaces/primeng/issues/4306

Tried a repro of this as per the test steps mentioned in https://github.com/primefaces/primeng/issues/4306 on the latest stable(62.0.3202.75) on Linux Ubuntu 14.04 both in both corp and non corp systems. 

Getting Warning and Errors when running 'npm install && ng serve', probably some dependency or incompatibility on the OS. Below is the error I am seeing when running the above command.

npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.1.2
npm WARN @schematics/angular@0.0.49 requires a peer of @angular-devkit/schematics@0.0.34 but none was installed.
npm ERR! Linux 4.4.0-66-generic
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "install"
npm ERR! node v4.2.6
npm ERR! npm  v3.5.2
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn

npm ERR! uglifyjs-webpack-plugin@0.4.6 postinstall: `node lib/post_install.js`
npm ERR! spawn ENOENT
npm ERR! 
npm ERR! Failed at the uglifyjs-webpack-plugin@0.4.6 postinstall script 'node lib/post_install.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the uglifyjs-webpack-plugin package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node lib/post_install.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs uglifyjs-webpack-plugin
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls uglifyjs-webpack-plugin
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/XXXX/Downloads/chrome62demo/npm-debug.log

Deleted: 781218.png 123 KB

	781218.png 123 KB View Download

Hi,
Thanks for trying to reproduce. You need to install Node 7.x, 4.x is too old. You can do so from here: 

https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions

Getting: 'nodejs is already the newest version (0.10.25~dfsg2-2ubuntu1)' when running sudo apt-get install -y nodejs after curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -.

Hi there,
Not sure why its saying that (your console log said you were running 4.x).

I made a precompiled/AoT version of the demo and put it on my personal server here:
https://cloud.slkdev.net/chrome62demo/

Note that on a production build like the above, the error message will like this instead of like in the original issue:

ERROR TypeError: Cannot read property 'remove' of undefined
    at e.remove (vendor.2e84276b1c47102a018d.bundle.js:1)
    at e._unlink (vendor.2e84276b1c47102a018d.bundle.js:1)
    at e._remove (vendor.2e84276b1c47102a018d.bundle.js:1)
    at e._mismatch (vendor.2e84276b1c47102a018d.bundle.js:1)
    at e.check (vendor.2e84276b1c47102a018d.bundle.js:1)
    at e.diff (vendor.2e84276b1c47102a018d.bundle.js:1)
    at e.ngDoCheck (vendor.2e84276b1c47102a018d.bundle.js:1)
    at Cn (vendor.2e84276b1c47102a018d.bundle.js:1)
    at pr (vendor.2e84276b1c47102a018d.bundle.js:1)
    at ur (vendor.2e84276b1c47102a018d.bundle.js:1)
    at Vr (vendor.2e84276b1c47102a018d.bundle.js:1)
    at Object.updateDirectives (main.aa0f6c7e527c1b76797b.bundle.js:1)
    at Object.updateDirectives (vendor.2e84276b1c47102a018d.bundle.js:1)
    at sr (vendor.2e84276b1c47102a018d.bundle.js:1)
    at _r (vendor.2e84276b1c47102a018d.bundle.js:1)

You should be able to follow the replication instructions using the above link:

1) Load page, open dev tools to watch console log
2) Start spamming toggling columns and it should happen within a few seconds. If it doesn't, rotate which ones you're doing. I can do it pretty reliably by spamming one column for about 5 seconds or so then clicking a different one.

In a minimal demo like this, it takes spamming for a few seconds because those are the only events being processed by the application, but in a large application it happens near 100%.

Thanks for the live demo and updated test steps.Able to reproduce the issue on the latest canary(64.0.3262.0) and the latest stable(62.0.3202.89) on Windows-10, Mac OS 10.12.6 and Linux Ubuntu 14.04 as per the steps mentioned in C#5.

This is regression issue broken in M-62.

Last good build: 62.0.3192.0
First bad build: 62.0.3193.0

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/bee7a4ff2af4c3fab525fad724201ec7fb1f9e27..c2cead62cb4879ad4d6dac91b9aeb30aa3eebc4d

V8 changelog:
=============
https://chromium.googlesource.com/v8/v8/+log/f1ee38ab..4a5eabed

marja@: Could this be related to https://chromium-review.googlesource.com/c/v8/v8/+/623047. Please help in assigning to appropriate owner if the change is unrelated.

Note: Tagging this with RB-Stable for M-62 since this is regressed in M-62 and just in case we plan a stable refresh.

My flag is not on in M62. So hmm... does this repro for stable M62?

Yes, this is reproducible on the latest canary(62.0.3202.89) of Windows-10. Attached is the screenshot of the same.

marja@: If your change is unrelated, could you please help in assigning to proper owner from the changelog: https://chromium.googlesource.com/v8/v8/+log/f1ee38ab..4a5eabed

Appreciate your help! 

Deleted: 781218.mp4 1.1 MB

	781218.mp4 1.1 MB View Download

If the fix (when determined) is able to get into a patch to stable that would be great. The severity of this issue is very high for affected sites. While we have to spam in the provided minimalistic demo because there is nothing else going on in the site, for larger applications this happens constantly if you're affected by it (no spamming required). That makes the affected applications currently completely unusable in Chrome.

Agree with starligh. In our case it is a very critical issue that completely blocked working with our solution.

I can repro with https://cloud.slkdev.net/chrome62demo/ as shown in the video in comment 8 with the given V8 and Chrome versions: Chrome r495923, V8 r47464.

(It's not my commit, but I'll bisect this anyway.)

gsathya@'s commit maybe?

01c82f9cab010b390f9ad15de9edf1fee44b972e is the first bad commit

commit 01c82f9cab010b390f9ad15de9edf1fee44b972e
Author: Sathya Gunasekaran <gsathya@chromium.org>
Date:   Sun Aug 20 18:58:40 2017 -0700

    Reland "[runtime] Store hash code in length field"
    
    This is a reland of decf5750c6421adf93b02135defa2b7c6c6fa755
    
    This patch fixes the hash code migration in the backing store
    transition case from Smi to PropertyArray in the IC system and
    Turbofan. Also, adds tests.
    
    Bug:  v8:6413 ,  v8:6404 
    
    Original change's description:
    > [runtime] Store hash code in length field
    >
    > Store the hash code in 21 bits of the length field.
    >
    > Change the GetIdentityHash API to be unhandlified, since there's no
    > property lookup anymore.
    >
    > Update js/ and test/ to match new API and expections.
    >
    > Bug:
    > Change-Id: I8dc75de4021f59e79b45f3f38ec997c3b3687b24
    > Reviewed-on: https://chromium-review.googlesource.com/589688
    > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
    > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#47259}
    
    Change-Id: I69289113c4b7978c46f6f9373cc972086ecb6822
    Bug:
    Reviewed-on: https://chromium-review.googlesource.com/614903
    Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
    Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#47459}

This fix might need a merge to M63.

+adamk@ 

gsathya@ - is there a workaround that can be used on client side? Do you know full impact of how widespread this is?

Just to confirm -- As of ToT content_shell today (3fdef810d4983e1c7640bee65fcf9591e5442fe4), I can reproduce this.

Although, if I run the same content_shell with --js-flags="--no-opt", I can not reproduce this. This seems like a JIT bug to me.

abdulsyed@: I would need further confirmation of the actual cause before commenting on either.

More debugging reveals that the key is a JSObject with a PropertyArray and we seem to have lost it's hash code (possibly in JSNativeContextSpecialization::BuildExtendPropertiesBackingStore?)

DebugPrint: 0x1d83d10a92c9: [JS_OBJECT_TYPE] in OldSpace
 - map = 0x2a5799dee591 [FastProperties]
 - prototype = 0x25517f7a2199
 - elements = 0x87c53b02251 <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties = 0x3527b5f4e459 <PropertyArray[3]> {
    #header: 0x3aab9417ceb9 <String[7]: Field A> (data field 0)
    #field: 0x87c53b07901 <String[1]: a> (data field 1)
    #_$visited: 0x87c53b02381 <true> (data field 2) properties[0]
 }
0x2a5799dee591: [Map]
 - type: JS_OBJECT_TYPE
 - instance size: 40
 - inobject properties: 2
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 2
 - enum length: 3
 - back pointer: 0x2a5799df9031 <Map(HOLEY_ELEMENTS)>
 - instance descriptors (own) #3: 0x205e2e08301 <FixedArray[11]>
 - layout descriptor: (nil)
 - prototype: 0x25517f7a2199 <Object map = 0x2a5799d822a1>
 - constructor: 0x25517f7a21d1 <JSFunction Object (sfi = 0x87c53b2e0c1)>
 - dependent code: 0x3f00e9f7ec19 <FixedArray[3]>
 - construction counter: 0

As opposed to the key with --no-opt

DebugPrint: 0x94f9e92d721: [JS_OBJECT_TYPE] in OldSpace
 - map = 0x1c29a3278181 [FastProperties]
 - prototype = 0x3f32f34a2199
 - elements = 0xc44a002251 <FixedArray[0]> [HOLEY_ELEMENTS]
 - hash = 13797  <---------------------------------------------- note the hashcode here
 - properties = 0xcfc01a17211 <PropertyArray[3]> {
    #header: 0x37f68487ca41 <String[7]: Field A> (data field 0)
    #field: 0xc44a007901 <String[1]: a> (data field 1)
    #_$visited: 0xc44a002381 <true> (data field 2) properties[0]
 }
0x1c29a3278181: [Map]
 - type: JS_OBJECT_TYPE
 - instance size: 40
 - inobject properties: 2
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 2
 - enum length: 3
 - back pointer: 0x1c29a3278f91 <Map(HOLEY_ELEMENTS)>
 - instance descriptors (own) #3: 0xcfc01a171a9 <FixedArray[11]>
 - layout descriptor: (nil)
 - prototype: 0x3f32f34a2199 <Object map = 0x1c29a32022a1>
 - constructor: 0x3f32f34a21d1 <JSFunction Object (sfi = 0xc44a02e0c1)>
 - dependent code: 0xc44a002251 <FixedArray[0]>
 - construction counter: 0

My initial hypothesis was that we had an object without any out of object properties but with a hashcode stored on the kPropertiesOrHashOffset, and then we did some sort of lowering that replaced the hash code with an EmptyFixedArray (.. which is used everywhere as a default). I went through all the uses of AccessBuilder::ForJSObjectPropertiesOrHash() and they all seem to make make sense to me.

Running with --trace-deopt, I see relevant functions ('e.check') being deoptimized which made me wonder if the deoptimizer and the materializer are re creating an incorrect property array. Looking at https://cs.chromium.org/chromium/src/v8/src/deoptimizer.cc?l=3588, I see that we don't do any masking to get the length -- I don't know enough about the materializer to determine if the masking was done before creating the translation frame? FWIW, we don't seem to be hitting this line of code (never hit a breakpoint on that line while running the testcase) so I don't think it's the cause of this bug. Also, running with '--no-turbo-escape' does reproduce this, so it confirms that the materializer isn't the problem here (unless ofc --no-turbo-escape is broken).

Reassigning to jaro to take a look at the turbofan code

Punting this to M-63 Stable release.

Does that have a target date associated with it? Because a growing number of us have a pile of angry customers completely unable to use our sites with Chrome.  This also impacts development for developers who have grown used to using Chrome Dev Tools, as you can't use them on a site constantly crashing. 

I am completely happy to explore workarounds if anyone has any guidance on that, but from what I understand, no workaround is known. I understand the potential complexity of the issue, but the severity is high when you're affected. I'm having to direct customers to use Firefox in the meantime, but not everyone is happy with that, and the exception is generated deep within the frameworks so I don't have the slightest clue how I could influence working around this issue.

When the browser auto updates and you can't downgrade, a totally breaking issue like this is a huge nightmare.

I understand your situation and apologize for the state of things. We don't know the exact cause of this bug which makes it hard to suggest a proper fix. 

At this point, all we know that is for certain  JSObjects (but not numbers or strings), the JIT loses the computed hash code (possibly on deopt), which breaks ES6 Map and Set. With only this information, I would suggest to use a polyfill for a Map/Set.

I will give that a try, thanks for the advice :-) Hopefully a proper fix can be found soon.

Unfortunately, polyfilling set/map is a no go for this issue at least. The portion of the widget in the demo that has an issue does not use es6 set or map:

https://github.com/primefaces/primeng/blob/master/src/app/components/multiselect/multiselect.ts

The crashing portion seems to be the backing options on the toggle in the demo, this is declared an any[] array. Inside this object, an entry of the array would typically look like this:

{ 
    label: label,
    value: {
        header: header,
        field: field
    }
}

It seems like the crash can occur two ways - randomly on accessing the data frequently (like spamming in the demo) -or- modifying the contents of the array, and then during the refresh of the UI as it redraws the changes. Both ways trigger the same stacktrace, so I'm assuming its the same root cause.

Don't know if this helps or not, but, that's what I observe.

Can you upload a copy of the version with the polyfill?

D8 repro (with --allow-natives-syntax)

var m = new Map();

function C() { }

for (var i = 0; i < 1000; i++) new C();


function f(o) {
  o.x = true;
}

f(new C());
f(new C());


var o = new C();

m.set({}, 3);
m.set(o, 1);  // This creates hash code on o.

// Add an out-of-object property.
o.x = true;
// Delete the property (so we have no out-of-object properties).
delete o.x;

%OptimizeFunctionOnNextCall(f);
f(o);
assertEquals(m.get(o), 1);

Fix is in the making.
Most probably this won't make it into M62 anynmore, M63 for certain though.

You can certainly mitigate this in JS until the fix is out. The offending function is equalsByValue in vendor.XXX.js. It temporarily adds a "_$visited" property to the incoming object, and deletes it after finishing.

Deleting properties is a very costly operation in V8 and should be avoided if possible. A simple fix would be set _$visited to true/false and never delete _$visited. This should also have a positive performance side-effect.

Here is what happens:

When we add and delete out-of-object property 'x', we leave an empty out-of-object property array in the object. The optimized code for "o.x = true" figures out (from meta-data) it needs to allocate a new property array, taking a hash from the property_array_or_hash if it was Smi. If the field was not smi, it just smashes no-hash sentinel as the hash code, effectively losing the hash code.

The best way is ensure that objects with no out-of-object properties keep their hash in the properties-or-hash field as Smi. That means that if we delete the last out-of-object property, we should move the hash code from the property array object to the object's properties-or-hash field (thus discarding the old property array).

Camillo offered to take it from here, re-assigning.

This is also affecting M-62.

Thank you for the detailed workaround advice. I passed it on downstream. Ironically, there is already an open issue in the primeng project saying that the equalsByValue/_$visited function you mentioned should be reimplemented.

I am using the Primeng and Angular2
Latest chrome is getting crash when we deselect the multiselect component of primeng.
The project is stagnant because of this issue. Please help us.

Error: 

ERROR TypeError: Cannot read property 'remove' of undefined
    at _DuplicateMap.webpackJsonp.../../../core/@angular/core.es5.js._DuplicateMap.remove (core.es5.js:7739)
    at DefaultIterableDiffer.webpackJsonp.../../../core/@angular/core.es5.js.DefaultIterableDiffer._unlink (core.es5.js:7436)
    at DefaultIterableDiffer.webpackJsonp.../../../core/@angular/core.es5.js.DefaultIterableDiffer._truncate (core.es5.js:7298)
    at DefaultIterableDiffer.webpackJsonp.../../../core/@angular/core.es5.js.DefaultIterableDiffer.check (core.es5.js:7145)
    at DefaultIterableDiffer.webpackJsonp.../../../core/@angular/core.es5.js.DefaultIterableDiffer.diff (core.es5.js:7081)
    at MultiSelect.webpackJsonp.../../../../primeng/components/multiselect/multiselect.js.MultiSelect.ngDoCheck (multiselect.js:75)
    at checkAndUpdateDirectiveInline (core.es5.js:10762)
    at checkAndUpdateNodeInline (core.es5.js:12137)
    at checkAndUpdateNode (core.es5.js:12105)
    at debugCheckAndUpdateNode (core.es5.js:12734)

That's the same issue (it's actually the multiselect component that's the problem with datatable as well). c#30 gives advice on how to workaround it but it would need to be implemented downstream in primeng. I passed the information on down.

CL is in-flight: https://chromium-review.googlesource.com/c/v8/v8/+/763230

We will have to bake it for several days on canary before we can start back merging.

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

commit eab2f2e654da8c0edfdd8a47a73432b07127321c
Author: Camillo Bruni <cbruni@chromium.org>
Date: Mon Nov 13 10:56:53 2017

Disallow empty PropertyArray as properties backing store

The only empty PropertyArray is the empty_property_array object on the
isolate. Allowing empty PropertyArrays causes the turbofan to ignore the
existing hash when growing the backing store again. We currently only end
up with the empty PropertyArray when following back transitions.

Bug:  chromium:781218 ,  chromium:783713 
Change-Id: If41dd09b965cdc8d957b9ca50ba3c8a7f4254769
Reviewed-on: https://chromium-review.googlesource.com/763230
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49318}
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/code-stub-assembler.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/factory.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/heap/heap.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/objects-debug.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/objects-printer.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/objects.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/objects.h
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/objects/map.h
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/runtime/runtime-object.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/runtime/runtime-test.cc
[modify] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/src/runtime/runtime.h
[add] https://crrev.com/eab2f2e654da8c0edfdd8a47a73432b07127321c/test/mjsunit/regress/regress-781218.js

M63 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge  into the release branch ASAP. Thank you.

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

commit 837ce0f9a33148106c68f1529bcd08e87e483e5a
Author: Camillo Bruni <cbruni@chromium.org>
Date: Tue Nov 14 09:14:18 2017

[test] Adjust empty PropertyArray regression test

Make sure we have at least two elements in the Map, otherwise we don't
perform a proper dictionary lookup.

Bug:  chromium:781218 
Change-Id: I471e3822b95c15e3a5b2ac54c8ad1f030bd54d40
Reviewed-on: https://chromium-review.googlesource.com/768708
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49345}
[modify] https://crrev.com/837ce0f9a33148106c68f1529bcd08e87e483e5a/test/mjsunit/regress/regress-781218.js

I'm waiting for the first canary coverage. The CL only made it into 64.0.3268.0 today. I should be able to backmerge tomorrow.

hablich@ for M63 merge review

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

LEt's merge to 63 after some coverage.

Please merge your change to M63 branch 3239 by 4:00 PM PT, tomorrow (Friday) so we can pick it up for next week Beta release. Thank you.

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

commit 7fc2305cee2e12eef37d1707b43f2bc91a059bf7
Author: Camillo Bruni <cbruni@chromium.org>
Date: Fri Nov 17 16:48:30 2017

Merged: Disallow empty PropertyArray as properties backing store

Revision: eab2f2e654da8c0edfdd8a47a73432b07127321c

BUG= chromium:781218 , chromium:783713 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=ishell@chromium.org

Change-Id: Iea6f73e16f2702dd20b01642e7d813f86b14f5ac
Reviewed-on: https://chromium-review.googlesource.com/776800
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/branch-heads/6.3@{#75}
Cr-Branched-From: 094a7c93dcdcd921de3883ba4674b7e1a0feffbe-refs/heads/6.3.292@{#1}
Cr-Branched-From: 18b8fbb528a8021e04a029e06eafee50b918bce0-refs/heads/master@{#48432}
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/code-stub-assembler.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/factory.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/heap/heap.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/objects-debug.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/objects-printer.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/objects.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/objects.h
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/objects/map.h
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/runtime/runtime-object.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/runtime/runtime-test.cc
[modify] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/src/runtime/runtime.h
[add] https://crrev.com/7fc2305cee2e12eef37d1707b43f2bc91a059bf7/test/mjsunit/regress/regress-781218.js

Seems like this is already merged to M63 at #46. Is there anything else pending for M63? If not, pls remove "Merge-Approved-63" label. Thank you.

#47, you are correct.

In general, whenever a v8 patch is merged, the associated bug will be labeled "merge-merged-<v8.version>". V8 versions, by convention, are always Chrome version divided by 10. so "merge-merged-6.3" is equivalent to "merge-merged-63" for Chrome's purposes.

There's a bug filed against the tooling at issue v8:5030, please comment on that issue if it would be useful to have this fixed in a general way.

Verified the issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.6 using chrome latest Beta M63-63.0.3239.59 by following steps mentioned in the comment #5 & 8. Observed that Run without random crashes in the java script console and its working as expected. Hence adding TE-Verified label.

Please find the screen shot for reference.

Thank you!

Deleted: 781218.ogv 4.8 MB

	781218.ogv 4.8 MB View Download