Bug 161436 - stress/random-53bit.js.ftl-no-cjit-no-inline-validate sometimes fails
Summary: stress/random-53bit.js.ftl-no-cjit-no-inline-validate sometimes fails
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-31 08:44 PDT by Filip Pizlo
Modified: 2016-08-31 14:05 PDT (History)
6 users (show)

See Also:


Attachments
Patch (5.78 KB, patch)
2016-08-31 12:20 PDT, Yusuke Suzuki
no flags Details | Formatted Diff | Diff
Patch (5.54 KB, patch)
2016-08-31 12:45 PDT, Yusuke Suzuki
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2016-08-31 08:44:16 PDT
I think this failure is rare.  It doesn't happen all the time because it probably depends on a particular return value from Math.random().
Comment 1 Filip Pizlo 2016-08-31 08:44:34 PDT
This is all it says when it fails:

stress/random-53bit.js.ftl-no-cjit-no-inline-validate: Exception: Error: OUT
stress/random-53bit.js.ftl-no-cjit-no-inline-validate: global code@random-53bit.js:23:24
stress/random-53bit.js.ftl-no-cjit-no-inline-validate: ERROR: Unexpected exit code: 3
Comment 2 Yusuke Suzuki 2016-08-31 09:19:21 PDT
Ooooops, thanks. Looking.
Comment 3 Yusuke Suzuki 2016-08-31 10:47:16 PDT
I think there are two possible reasons.

1.
By design, this test rarely may fail.
We can reduce this rate by increasing MAX value.
It may solve the issue.

2.
It may be caused by the specific random seed patterns.


If (1) is the reason, everything is ok. We can just increase the MAX value.
But if (2) is the reason, there should be some issues.
To validate the reason, I'm infinitely executing this test now.
Comment 4 Yusuke Suzuki 2016-08-31 11:09:20 PDT
Reproduced. Failed pattern is the following.

https://gist.github.com/Constellation/0f43a235e6e43bfc9ab7ddc4a537757a

And I'll dump the random seed...
Comment 5 Yusuke Suzuki 2016-08-31 11:47:16 PDT
OK, this is just because accidentally some random sequence is shown.
I'll tweak the test to reduce this rate.
Comment 6 Yusuke Suzuki 2016-08-31 12:20:31 PDT
Created attachment 287526 [details]
Patch
Comment 7 Filip Pizlo 2016-08-31 12:37:57 PDT
Comment on attachment 287526 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=287526&action=review

> JSTests/stress/random-53bit.js:25
> -for (var i = 0; i < 1e4; ++i) {
> +for (var i = 0; i < 1e2; ++i) {

I don't think this is a good idea.  Eager tests mean that they compile with less profiling, which may lead the compiler to make different decisions.  I've only seen this fail in a non-eager config, and I don't think you can be sure that an eager test would catch a non-eager failure.
Comment 8 Yusuke Suzuki 2016-08-31 12:43:26 PDT
Comment on attachment 287526 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=287526&action=review

>> JSTests/stress/random-53bit.js:25
>> +for (var i = 0; i < 1e2; ++i) {
> 
> I don't think this is a good idea.  Eager tests mean that they compile with less profiling, which may lead the compiler to make different decisions.  I've only seen this fail in a non-eager config, and I don't think you can be sure that an eager test would catch a non-eager failure.

Make sense.
Just increasing the MAX value should solve the problem.
Comment 9 Yusuke Suzuki 2016-08-31 12:45:52 PDT
Created attachment 287529 [details]
Patch
Comment 10 WebKit Commit Bot 2016-08-31 14:05:30 PDT
Comment on attachment 287529 [details]
Patch

Clearing flags on attachment: 287529

Committed r205267: <http://trac.webkit.org/changeset/205267>
Comment 11 WebKit Commit Bot 2016-08-31 14:05:34 PDT
All reviewed patches have been landed.  Closing bug.