callback function not called any more after called lots of times and in different place.
Reported by
sushuang...@gmail.com,
Mar 1 2016
|
|||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36
Steps to reproduce the problem:
1. Download the attached file canary-problem.zip and unzip it.
2. Open canary-problem.html in Chrome Canary 51.0.2663.0 (can also be other 51.0.x, I guess). Then you will see a scatter chart shown in browser.
3. Open the Chrome Developer Tool.
4. Using mouse dragging in the chart area (mouse down and mouse move for a while). You will see dots in the scatter chart moves following the mouse.
5. With a great probability an error will be printed ('Something wrong! Method "each" does not call callback.'). That means the callback method is not entered.
What is the expected behavior?
"window.each0" should call callback method of normally, but not miss it.
What went wrong?
Open the file "echarts-all-3.0.0.js", you can see the method "window.each0" and "window.testCallbackMiss" at the head.
"each0" is widely used throughout the program.
The movement "dragging chart" is just a trigger to show this problem. When dragging, "each0" is called for a lot times and at different place. Sometimes the callback of "each0" is missed abnormally (testCallbackMiss log error message at that moment).
If we add a sentence "arguments.callee;" in method "each0", this problem will not happen any more. So I guess this problem is caused by chrome optimizing. When "arguments.callee" used, optimizing is not adopted, and this problem disappear.
Did this work before? N/A
Chrome version: 51.0.2663.0 canary (64-bit) Channel: n/a
OS Version: OS X 10.9.0
Flash Version: Shockwave Flash 20.0 r0
,
Mar 1 2016
,
Mar 2 2016
Let's wait for the bisection.
,
Mar 2 2016
Able to reproduce the issue on win8.1, mac 10.11 chrome version 51.0.2663.0 and 50.0.2657.0 This is a regression in M50 and below is the bisect info Manual Bisect Good Build: 50.0.2653.0 Bad Build: 50.0.2654.0 Bisect Tool Info: https://chromium.googlesource.com/chromium/src/+log/18e572b44864aebb66398514fc0a41f43fa4a3e1..0c56dabf4895816405464b4955d4824c56e450a3 Possible suspect from the v8-roll https://chromium.googlesource.com/v8/v8/+/ede69c4978be9575ee79cae48766bd707b10d291 Please reassign if this is not related to your change.
,
Mar 2 2016
The x87 suspect CL makes no sense.
,
Mar 2 2016
Reduced repro:
var o = {}
var p = {foo: 1.5}
function g(x) { return x.foo === +x.foo; }
assertEquals(false, g(o));
assertEquals(false, g(o));
%OptimizeFunctionOnNextCall(g);
assertEquals(false, g(o)); // Still fine here.
assertEquals(true, g(p));
%OptimizeFunctionOnNextCall(g);
assertEquals(false, g(o)); // Confused by type feedback.
function f(x) { return x === +x; }
assertEquals(false, f(undefined));
assertEquals(false, f(undefined));
%OptimizeFunctionOnNextCall(f);
assertEquals(false, f(undefined)); // Interestingly this fails right away.
This is without a doubt caused by https://codereview.chromium.org/1704833002 ("[crankshaft] Make sure +x is as fast as Number(x)"). Please fix or revert (also on the 5.0 branch).
,
Mar 2 2016
See my comment on that codereview for what's going on.
,
Mar 2 2016
Thanks Jakob for the investigation. Fix uploaded.
,
Mar 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/0c35579093dc5e286ad89e5c7bde3aeb355def07 commit 0c35579093dc5e286ad89e5c7bde3aeb355def07 Author: bmeurer <bmeurer@chromium.org> Date: Wed Mar 02 19:26:13 2016 [crankshaft] Fix invalid ToNumber optimization. We cannot optimize away ToNumber conversions based on the Type that we see in Crankshaft, as this might be the (unchecked or even pretruncated) lower bound. We can only use the HType, which is based on the definition. R=jkummerow@chromium.org BUG= chromium:590989 LOG=n Review URL: https://codereview.chromium.org/1757013002 Cr-Commit-Position: refs/heads/master@{#34445} [modify] https://crrev.com/0c35579093dc5e286ad89e5c7bde3aeb355def07/src/crankshaft/hydrogen.cc [modify] https://crrev.com/0c35579093dc5e286ad89e5c7bde3aeb355def07/src/crankshaft/hydrogen.h [add] https://crrev.com/0c35579093dc5e286ad89e5c7bde3aeb355def07/test/mjsunit/regress/regress-crbug-590989-1.js [add] https://crrev.com/0c35579093dc5e286ad89e5c7bde3aeb355def07/test/mjsunit/regress/regress-crbug-590989-2.js
,
Mar 3 2016
Issue 587025 has been merged into this issue.
,
Mar 3 2016
This needs back-merging to M50 once we have some canary coverage.
,
Mar 3 2016
You can mark it like this to mark it for a future merge.
,
Mar 8 2016
Should back-merge cleanly; otherwise please find someone to do the backmerge (should be safe by now).
,
Mar 10 2016
,
Mar 10 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/65b894ceaf2becead2324fd0b7acd9d8f8b1f72e commit 65b894ceaf2becead2324fd0b7acd9d8f8b1f72e Author: Michael Hablich <hablich@chromium.org> Date: Thu Mar 10 13:51:59 2016 Version 5.0.71.15 (cherry-pick) Merged 0c35579093dc5e286ad89e5c7bde3aeb355def07 [crankshaft] Fix invalid ToNumber optimization. BUG= chromium:590989 LOG=N R=jkummerow@chromium.org, bmeurer@chromium.org Review URL: https://codereview.chromium.org/1773183007 . Cr-Commit-Position: refs/branch-heads/5.0@{#21} Cr-Branched-From: ad16e6c2cbd2c6b0f2e8ff944ac245561c682ac2-refs/heads/5.0.71@{#1} Cr-Branched-From: bd9df50d75125ee2ad37b3d92c8f50f0a8b5f030-refs/heads/master@{#34215} [modify] https://crrev.com/65b894ceaf2becead2324fd0b7acd9d8f8b1f72e/include/v8-version.h [modify] https://crrev.com/65b894ceaf2becead2324fd0b7acd9d8f8b1f72e/src/crankshaft/hydrogen.cc [modify] https://crrev.com/65b894ceaf2becead2324fd0b7acd9d8f8b1f72e/src/crankshaft/hydrogen.h [add] https://crrev.com/65b894ceaf2becead2324fd0b7acd9d8f8b1f72e/test/mjsunit/regress/regress-crbug-590989-1.js [add] https://crrev.com/65b894ceaf2becead2324fd0b7acd9d8f8b1f72e/test/mjsunit/regress/regress-crbug-590989-2.js
,
Mar 10 2016
,
Mar 10 2016
,
Mar 18 2016
|
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by chrishtr@chromium.org
, Mar 1 2016Labels: ReleaseBlock-Beta M-51 Needs-Bisect
Status: Untriaged (was: Unconfirmed)