Bug 90003
Summary: | [chromium] fast/js/repeat-cached-vm-reentry.html is timing out on Mac (dbg) and Win (dbg) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Hin-Chung Lam <hclam> |
Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | antonm, arv, dpranke, jkummerow |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Hin-Chung Lam
Blamelist r121233:121239
Log: http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Win%20%28dbg%29%282%29/builds/10767/steps/webkit_tests/logs/stdio
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Hin-Chung Lam
Committed r121276: <http://trac.webkit.org/changeset/121276>
Hin-Chung Lam
Adding arv@ since he last touched the test script.
Erik Arvidsson
This makes no sense. That blame list seem unrelated to this.
I'm a bit concerned though. If this is really a flakiness in V8 it might have bad long term issues.
Anton, do you know who on the V8 team might be able to look at this. It is most likely just flakiness in the test runner but the code is simple enough.
Hin-Chung Lam
Yeah the blame list doesn't make sense to me either but that what is shown by flakiness dashboard.
Hin-Chung Lam
The test was flaky before too:
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=repeat-cached-vm-reentry.html
Dirk Pranke
if you look at the full history we have for this test, all three periods of flakiness are triggered by v8 rolls, and go away when the v8 roll is reverted or changed:
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fjs%2Frepeat-cached-vm-reentry.html
looks like a v8 problem to me, not flakiness at all.
Jakob Kummerow
Thanks for the detailed analysis of affected revisions ranges. This is indeed a V8 problem.
It turned out to be relatively benign: in debug mode, there's a checking routine that is quadratic in the number of optimized closures, and this particular test happens to create a huge number of closures that due to recent improvements in V8 now share their optimized code. Release mode is not affected.
I have landed a workaround in V8's bleeding_edge branch, which will probably roll into Chromium tomorrow or so (look for V8 version 3.12.8).
As a side note, this test is pretty braindead and essentially tests undefined behavior (namely, sorting an array with a comparator function that always returns 1). We are lucky that it passes at all :-)
Stephen Chenney
Marked LayoutTest bugs, bugs with Chromium IDs, and some others as WontFix. Test failure bugs still are trackable via TestExpectations or disabled unit tests.