From b671b6ce2ccbff5e1b735293bcf7fe94a5b65971 Mon Sep 17 00:00:00 2001 From: Alon Zakai Date: Fri, 8 Mar 2024 15:19:20 -0800 Subject: Fuzzer: Fix up null outputs in wasm2js optimized builds (#6374) This is fallout from #6310 where we moved to use fuzz_shell.js for all fuzzing purposes. That script doesn't know wasm types, all it has on the JS side is the number of arguments to a function, and it passes in null for them all regardless of their type. That normally works fine - null is cast to the right type upon use - but in wasm2js optimized builds we can remove casts, which can make that noticeable. --- scripts/fuzz_opt.py | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'scripts/fuzz_opt.py') diff --git a/scripts/fuzz_opt.py b/scripts/fuzz_opt.py index 0d720c8f7..8bef4e98c 100755 --- a/scripts/fuzz_opt.py +++ b/scripts/fuzz_opt.py @@ -1059,6 +1059,21 @@ class Wasm2JS(TestCaseHandler): # start with the normal output fixes that all VMs need x = fix_output(x) + # replace null with 0. the fuzzing harness passes in nulls instead + # the specific type of a parameter (since null can be cast to + # anything without issue, and all fuzz_shell.js knows on the JS side + # is the number of parameters), which can be noticeable in a + # situation where we optimize and remove casts, like here: + # + # function foo(x) { return x | 0; } + # + # When optimizing we can remove that | 0, which is valid if the + # input is valid, but as we said, the fuzz harness passes in a value + # of the wrong type - which would be cast on use, but if we remove + # the casts, we end up returning null here and not 0, which the + # fuzzer can notice. + x = re.sub(r' null', ' 0', x) + # check if a number is 0 or a subnormal, which is basically zero def is_basically_zero(x): # to check if something is a subnormal, compare it to the largest one -- cgit v1.2.3