This might sound silly, But I was confused by the failed zig build test --fuzz command both on 0.16.0 and master. And thought the fuzz functionality is broken.
Currently the fuzz only works on ReleaseFast, So maybe we specify the command in the init main.zig to avoid confusion?
It would be better if someone familiar with the fuzz to write up a doc though.
This might sound silly, But I was confused by the failed `zig build test --fuzz` command both on 0.16.0 and master. And thought the fuzz functionality is broken.
Currently the fuzz only works on ReleaseFast, So maybe we specify the command in the init main.zig to avoid confusion?
It would be better if someone familiar with the fuzz to write up a doc though.
So the actual reason for the panic (that is the reason for the failed fuzz command) is that a safety check has failed. And it's not a good idea to give advice for just disabling the safety checks (as that would be the reason for undefined behavior then). (this was just my first thought; isn't the root of the problem, but might be valuable in general; the second one - that is below - is more relevant here)
Also, when you build in Debug mode, Zig uses its own self-hosted backend, which crashes when fuzzing (see #30655). All release optimizations (ReleaseSafe, ReleaseFast, ReleaseSmall) use the LLVM backend. ReleaseSmall does crash for another reason, but ReleaseSafe does not. And when ReleaseSafe instead of ReleaseFast is used, the LLVM backend emits optimized code that is still safety-checked (so no "undefined behavior").
So the actual reason for the panic (that is the reason for the failed fuzz command) is that a safety check has failed. And it's not a good idea to give advice for just disabling the safety checks (as that would be the reason for undefined behavior then).
*(this was just my first thought; isn't the root of the problem, but might be valuable in general; the second one - that is below - is more relevant here)*
Also, when you build in `Debug` mode, Zig uses its own self-hosted backend, which crashes when fuzzing (see #30655). All release optimizations (`ReleaseSafe`, `ReleaseFast`, `ReleaseSmall`) use the LLVM backend. `ReleaseSmall` does crash for another reason, but `ReleaseSafe` does not. And when `ReleaseSafe` instead of `ReleaseFast` is used, the LLVM backend emits optimized code that is still safety-checked (so no "undefined behavior").
@sfiedler Thanks for the info. I know this edit only provide a tiny value to someone trying out the fuzz at current status, and it's not sound and complete. Anyways, I guess we'll leave this issue here in case someone searched for it can get this info.
@sfiedler Thanks for the info. I know this edit only provide a tiny value to someone trying out the fuzz at current status, and it's not sound and complete. Anyways, I guess we'll leave this issue here in case someone searched for it can get this info.
So the actual reason for the panic (that is the reason for the failed fuzz command) is that a safety check has failed.
To be clear it's because the self-hosted backend doesn't emit the correct instrumentation symbols or something like that and that --fuzz flag crashes when it isn't there.
I think the change you have put forth @c19 would be good mostly because it's an extremely confusing error that you encounter having to go to codeberg issues to find the solution. This was discussed on a zulip thread and Andrew suggests that the --fuzz flag maybe should default to ReleaseSafe optimizations.
@sfiedler wrote in https://codeberg.org/ziglang/zig/pulls/35336#issuecomment-15187467:
> So the actual reason for the panic (that is the reason for the failed fuzz command) is that a safety check has failed.
To be clear it's because the self-hosted backend doesn't emit the correct instrumentation symbols or something like that and that `--fuzz` flag crashes when it isn't there.
I think the change you have put forth @c19 would be good mostly because it's an extremely confusing error that you encounter having to go to codeberg issues to find the solution. This was discussed on a [zulip thread](https://zsf.zulipchat.com/#narrow/channel/454360-compiler/topic/should.20.60--fuzz.60.20be.20implying.20.60.2Euse_llvm.20.3D.20true.60/near/594139189) and Andrew suggests that the `--fuzz` flag maybe should default to `ReleaseSafe` optimizations.
Some checks are pending
ci / aarch64-freebsd-debug (pull_request) Blocked by required conditions
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
No due date set.
Dependencies
No dependencies set.
Reference
ziglang/zig!35336
Loading...
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "c19/zig:master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?