New issue
Advanced search Search tips

Issue 594506 link

Starred by 3 users
Status: Duplicate
Merged: issue 590989
Owner:
bmeu...@chromium.org
Closed: Mar 2016
Cc:
verwa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment

JavaScript Optimization failure results in incorrect code execution

Reported by rol...@lagoa.com, Mar 14 2016 
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Steps to reproduce the problem:
* Open the attached test.html
* It prints the number of succeeded and failed tests

What is the expected behavior?
All tests should succeed

What went wrong?
The attached file contains a few functions from undersore.js and a simple test function that repeatedly executes an _.find with a predicate on a simple object. 

Even though the data structure is always the same, the find is able to find the entry in the data structure only the first few hundred/thousand times and then fails. The number of successes/failures is non deterministic. We also observed cases where the function worked in the debugger when single-stepping through it, but fails when executed without debugger/stepped over via F10. We did some minor changes (adding a counter that is never used and a comment) to the _.each function and it worked again. So we think, this might be a problem with the optimizing JIT compiler.

Did this work before? Yes two days ago (the newest Chrome beta update, the version given above, broke it)

Chrome version: Version 50.0.2661.26 beta-m (64-bit)  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0
TestCase.zip
1.5 KB Download

Comment 1 by c...@configit.com, Mar 14 2016 

We are seeing exactly the same issue on the latest beta and dev channel releases.

The reproduction provided is in common with our findings, as is the observations when the code is stepped through.

Additionally, we deploy our js minified and in this case do not see the problem.

All of these things pointed us to thinking it could likely be an optimisation issue also.

Comment 2 by bokan@chromium.org, Mar 14 2016

Components: -Blink Blink>JavaScript
Labels: -OS-Windows OS-All
Owner: hablich@chromium.org
Status: Untriaged (was: Unconfirmed)
This appears fixed in the latest Canary but I did reproduce it in Beta. Hosted for convenience at: http://bokan.ca/bugs/594506/test.html

Bisect points to this range:

https://chromium.googlesource.com/chromium/src/+log/29a24a77f2641ec45924093e06049ad03cdcaa5a..0c56dabf4895816405464b4955d4824c56e450a3

Which has this V8 roll:

https://chromium.googlesource.com/v8/v8/+log/382601d9..7a9f84b6

Perhaps we need to merge a fix back to the Beta branch?

Comment 3 by hablich@chromium.org, Mar 14 2016

Cc: bmeu...@chromium.org
Labels: -Pri-2 Merge-TBD-5.0 Pri-1
Owner: verwa...@chromium.org
Status: Assigned (was: Untriaged)
Thanks for the report.

verwaest@, is this related to your CLs in the mentioned range or Benedikt's?

I agree that this should be merged back to 50.

Comment 4 by verwa...@chromium.org, Mar 17 2016

Cc: -bmeu...@chromium.org verwa...@chromium.org
Owner: bmeu...@chromium.org
My changes aren't crankshaft related, so it must be Benedikt's.
Is that CL the one that introduced the bug? Or the one that fixed it? That CL is known to contain a bug. The fix was merged back as 5.0.71.15: https://codereview.chromium.org/1773183007. The version used in the report is 5.0.71.13, so it's definitely possible.

Comment 5 by bmeu...@chromium.org, Mar 18 2016

Mergedinto: 590989
Status: Duplicate (was: Assigned)

Comment 6 by bmeu...@chromium.org, Mar 22 2016

Labels: -Merge-TBD-5.0
►

Sign in to add a comment