-
Notifications
You must be signed in to change notification settings - Fork 786
Fuzz failures after #2702 #2788
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
Comments
Have a feeling that this has something to do with the runner being a bit more forgiving now, going to look into this! |
So far found that
triggers the problem. Now throwing it at Reduced: a.reduced.wasm.gz |
After fixing
|
Try adding |
Thanks, updated the output :) |
Is this after running wasm-reduce? I'm surprised it wouldn't have reduced the program more. Otherwise my next step would be to dive in with gdb:
Side note: I'm not sure when |
Yeah, that's after
Going to look into using gdb, hope this doesn't have unforeseen consequences in WSL :) |
What I can tell so far is that there's a (local.get $163) returning a Flow with a single The corresponding (tuple.make
(v128.const i32x4 0x00000000 0x00000000 0x00000000 0x00000000)
(ref.null)
(i64.const 0)
) running through a |
wasm-reduce doesn't work well on testcases like this, because the multivalue stuff increases the size every time you save. So it think it's failing to reduce and stops early. I thought I opened an issue for that but looks like not? You can reduce with |
Oh, appears the cause is the |
Postmortem: dcode should not use |
a.wasm.gz
Bisected this to have started with #2702
cc @dcodeIO
The text was updated successfully, but these errors were encountered: