ufuzz failures

[alexlamsl]

https://github.com/alexlamsl/UglifyJS2/runs/270406310
https://github.com/alexlamsl/UglifyJS2/runs/270429574
https://github.com/alexlamsl/UglifyJS2/runs/270450005

https://travis-ci.org/alexlamsl/UglifyJS2/builds/601434471
https://travis-ci.org/alexlamsl/UglifyJS2/builds/601439123
https://travis-ci.org/alexlamsl/UglifyJS2/builds/601442590
https://travis-ci.org/alexlamsl/UglifyJS2/builds/601446229
https://travis-ci.org/alexlamsl/UglifyJS2/builds/601449990
https://travis-ci.org/alexlamsl/UglifyJS2/builds/601453453

@kzc I might have gone insane, but none of these cases are making any sense to me 😓

[alexlamsl]

Never mind, I think I know why 😅

[kzc]

How long have you been fuzzing with pure_getters? I thought there was a reason we didn't use it at the time.

Suspicious compress options:

  pure_getters

[kzc]

What did the problem turn out to be?

[alexlamsl]

How long have you been fuzzing with pure_getters?

It's in the defaults for a very long time now, so I'd consider it to be stable.

What did the problem turn out to be?

It was me merging two separate fixes, the result of which leads to an avalanche of fuzzing failures 😞

[alexlamsl]

ufuzz on GitHub Actions manages to uncover older bugs that goes back to 3.3.0 so far, which have been keeping me busy.

[kzc]

Any idea why ufuzz on TravisCI and Github Actions behaves differently? Just by virtue of being faster it uncovers more bugs on Actions? Or do newer versions of Node have a better RNG?

[alexlamsl]

Even with its current configuration of using only 40% of available execution resources, running ufuzz on GitHub Actions is 3~4x faster than on Travis CI.

And without using all the parallel job slots, we can now have it perpetually running in the background without blocking CI runs from PRs and pushes, so we are talking about at least an order of magnitude more fuzzing than before.

[alexlamsl]

And now Node.js 13.0.1 is available... -ish

https://travis-ci.org/alexlamsl/UglifyJS2/builds/601828314#L151-L156

$ nvs --version
Downloading bootstrap node from https://nodejs.org/dist/v10.12.0/node-v10.12.0-linux-x64.tar.xz
curl: (56) GnuTLS recv error (-110): The TLS connection was non-properly terminated.

/home/travis/.nvs/nvs.sh: line 123:  3330 Segmentation fault      /home/travis/.nvs/cache/node /home/travis/.nvs/lib/index.js --version

https://travis-ci.org/alexlamsl/UglifyJS2/builds/601819544#L155-L156

$ nvs add node/$NODE
[######################################################-]  99% 2.0s
SHASUM256 does not match for cached file: node-v13.0.1-linux-x64.tar.xz

[kzc]

Node 13 probably won't be stable for several months.

Regarding pure_getters, I keep forgetting about the non-boolean option (strict) that is the default:

         pure_getters    : !false_by_default && "strict",

I vaguely recall that pure_getters=true was problematic in fuzzing due to getter and setter generation.

[alexlamsl]

Yes, pure_getters=true is unsafe, just as keep_fargs=true (hint: they both have a strict option 👻)

As for Node.js, their download server is basically down and out as per nodejs/build#1993