PreserveImportsExportsJS Fuzzer: Fix reduction

[kripken]

This fuzzer generates its own files, so reducing it needs some hacks,
unfortunately. Another option might be to separate this fuzzer out
entirely to its own file, or to at least not run multiple fuzzers on the
same testcase (see below), but I'm not sure those are better options.

When the main fuzzer runs multiple internal testcase handlers on a
single wasm file, we must make sure while reducing that only
PreserveImportsExportsJS receives its wasm. That wasm only works
with its JS, so other fuzzers will fail on it. To do so, use an env var
BINARYEN_PIEJS_WASM which tells the fuzzer we are reducing
in such a situation. The fuzzer reduction script then passes in the
reduced file that way, rather than the usual way, so other fuzzers
do not notice it.

Also rename orig.wasm to initial.wasm as this was confusing
given that reduction always starts from original.wasm.

[aheejin]

Haven't read this all yet (I've got to go now) but a typo.
(In case another person LGTMs it don't wait for me)

[aheejin]

BINARYEN_PIEJS_WASM is a file name and not 0/1, based on the code below

  BINARYEN_PIEJS_WASM={temp_wasm} ./scripts/fuzz_opt.py {auto_init} --binaryen-bin {binaryen_bin} 

[tlively]

As an alternative approach, how about we give the fuzzer options to say what fuzz handler to run? Then the reducer script can specify exactly the failing handler. This would be useful for manual investigations as well. A tricky bit is that random choices in one handler should never be affected by previous handlers so that reducing the number of handlers executed does not change their behavior. This could be done by snapshotting the random state before executing each handler and restoring it afterward.

[kripken]

@tlively Hmm, I think that not running multiple fuzzers on the same testcase would be simpler than that, and would also fix this. It would make us slightly less efficient, but probably not in a significant way. Or did you see other benefits to the other ideas?

[tlively]

or to at least not run multiple fuzzers on the same testcase (see below)

I'm not sure what "see below" is referring to here.

Not running multiple fuzzers on the same test case sounds good, too. It will make manual reproduction of problems slightly easier as well because there will less irrelevant logging for the bad seed. If we're not concerned about that change reducing our coverage throughput, it sgtm.

[aheejin]

+1 on not running multiple fuzzers if possible. It took me a while to wrap my head around this...

[aheejin]

Does this flag still exist?

[kripken]

Yes, this is still a useful flag sometimes. Less processing on each reduction iterations sometimes helps (though I don't remember a concrete example).

[aheejin]

Does this flag exist now?

[kripken]

(same question?)

[kripken]

@tlively

I'm not sure what "see below" is referring to here.

Sorry, it was just referring to the explanation after that, which said that our running multiple handlers on one testcase is the root issue. One handler runs, and another, and we want to give the other a file that the first can't handle.

Ok, then I'll look into the simplification of running a single handler at once, closing this for now.