-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve --reduce-test
#3719
improve --reduce-test
#3719
Conversation
Makes sense. I recognize that label body code that worked at one point. It may have broken after the big fyi,
|
Likewise, the original case produced different results with different versions of Node:
|
10110aa
to
b0d2bb3
Compare
Yeah, I've totally forgotten about that - pushed a new test case that is universal across all Node.js versions. |
There's also this 💎 $ node -v
v8.17.0
$ node
> require('./test/sandbox').run_code('var a,b=0;for(b in this)console.log(b)')
'a\nb\n' $ node -v
v10.18.1
$ node
> require('./test/sandbox').run_code('var a,b=0;for(b in this)console.log(b)')
'b\na\n' |
Globals traversal is apparently undefined behavior. Although property ordering is well defined in JS as order of definition, it's up to the JS engine to determine how it optimizes certain code. Side note: when I was testing the original reduce_test implementation on old ufuzz test cases with the commit rolled back accordingly I'd frequently get unrelated |
That's most likely due to the missing |
b0d2bb3
to
3c5fbfb
Compare
An example of a NaN/undefined reduced test case is seen above in latest master, with that toplevel patch in effect. |
My point was that a false positive reduced test case may on occasion mask a genuine bug. You cannot pick what's a good reduced test case and what is not - the algorithm will converge on one or the other as influenced by its environment (node globals, timeouts, whatever). |
Indeed − currently unless it's a clear false positive I tend to use the reduced test case to figure out what to modify in the original test case, then run to verify that is the only site that makes a difference. |
Just discovered that we can't reliably use |
3c5fbfb
to
3ec28f8
Compare
Any idea why I cannot reproduce the output of the non-minified reduced result of I put the reduced test case in a file named
|
- cover missing cases when eliminating unreferenced labels - format multi-line outputs correctly
3ec28f8
to
aeffe20
Compare
That is most bizarre indeed − $ node
> process.version
'v0.10.48'
> vm.runInNewContext(fs.readFileSync("0.js", "utf8"), { console: console })
undefined
undefined $ node
> process.version
'v0.12.18'
> vm.runInNewContext(fs.readFileSync("0.js", "utf8"), { console: console })
0
undefined $ node
> process.version
'v4.9.1'
> vm.runInNewContext(fs.readFileSync("0.js", "utf8"), { console: console })
0
undefined $ node
> process.version
'v6.17.1'
> vm.runInNewContext(fs.readFileSync("0.js", "utf8"), { console: console })
0
undefined $ node
> process.version
'v8.17.0'
> vm.runInNewContext(fs.readFileSync("0.js", "utf8"), { console: console })
undefined
undefined $ node
> process.version
'v10.18.1'
> vm.runInNewContext(fs.readFileSync("0.js", "utf8"), { console: console })
undefined
undefined $ node
> process.version
'v12.14.1'
> vm.runInNewContext(fs.readFileSync("0.js", "utf8"), { console: console })
undefined
undefined |
No discrepancies between Node.js versions if you replace |
So some NaN/undefined/Infinity false positives are actually false false positives. But the real problem is stranger still - obviously the code for 0.js was generated from the same version of node v6.9.0 by |
Because even on the same Node.js version, |
Ideally |
That may be the reason why I got so many NaN/undefined/Infinity redefinition reduced test cases when creating reduce_test. |
Just curious − why do you settle on Node.js 6? |
No particular reason. It works. With more packages going native async I'll be forced to upgrade soon. |
@kzc this is #3716 (comment)