Closed teymour-aldridge closed 2 years ago
Thanks for filing this issue! I think I know what's happening (and unfortunately there is not much you can do to fix it as a user). Do you have a public repo I can use to reproduce it? If not, don't worry.
(If you're comfortable with that, you can also email me the code so that it stays private)
I was originally experimenting in a private project, but I also have a public one where the same error occurs: https://github.com/bailion/compiler/blob/main/logic/src/fuzzcheck/parse.rs.
Thanks a lot. I will publish an update with the fix by the end of next week at the latest.
I have just published fuzzcheck 0.7.1. Could you let me know if it resolves the issue or if you encounter other problems? Thanks.
It fixes this issue (yay!) but I'm now getting a different error:
thread 'main' panicked at 'failed to properly link the different LLVM
coverage sections: CannotFindFunctionRecordAssociatedWithPrfData',
/Users/teymouraldridge/.cargo/registry/src/github.com-1ecc6299db9ec823/fuzzcheck-0.7.1/src/code_coverage_sensor/mod.rs:49:14
On 09/08/2021 11:22, Loïc Lecrenier wrote:
I have just published fuzzcheck 0.7.1. Could you let me know if it resolves the issue or if you encounter other problems? Thanks.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/loiclec/fuzzcheck-rs/issues/10#issuecomment-895110854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKFSTPIPXGVVMLM4BCOJDYLT36T5HANCNFSM5BWHQE7Q.
argh, that's annoying. I thought that might happen, but I don't really understand it, so it might take longer to fix. In the meantime, can you try it again, but this time adding:
[profile.release]
codegen-units = 1
lto = "thin" # maybe not necessary
to your Cargo.toml
? (if you use a workspace, it must be in the Cargo.toml
at the root of the workspace)
That got rid of that error, but another one has appeared
thread 'main' panicked at 'failed to parse LLVM prf_data: InconsistentCounterPointersAndLengths', /Users/teymouraldridge/.cargo/registry/src/github.com-1ecc6299db9ec823/fuzzcheck-0.7.1/src/code_coverage_sensor/mod.rs:46:71
hm, that one is surprising. Thanks a lot for your help, I'll try and figure it out.
I couldn't reproduce the issue on https://github.com/bailion/compiler/blob/main/logic/src/fuzzcheck/parse.rs . Does it also fail for you on that project? If not, do you have a public repo where the same error happens?
Has that ever happened again? A few things have changed since then. I am going to close the issue in ~a week otherwise.
I haven't encountered the issue since, although sometimes it crops up when calling cargo test
rather than cargo fuzzcheck
(which makes sense, but it might be helpful to also report an error message suggesting calling cargo fuzzcheck
)
right! I need to think about what should happen when cargo test
is run. Right now, it's supposed to do nothing but I've implemented that badly and it just doesn't work.
Since fuzzcheck
is kind of a heavy dependency, I am wondering whether I should recommend gating all its uses under cfg(fuzzing)
(which is set by cargo-fuzzcheck
). In that case, the test wouldn't exist in the first place.
That would make sense to me (example-based tests are definitely different to fuzzers in my mind) – Tarpaulin (xd009642/tarpaulin) also does something similar.
I encountered this crash while trying to run
cargo-fuzzcheck
.This is using the
nightly-x86_64-apple-darwin
toolchain (rustc 1.56.0-nightly (b70888601 2021-07-28)
)I'm currently experimenting with different
rustc
versions to see if that makes a difference.I'm using the latest version of both
fuzzcheck
andcargo-fuzzcheck
(0.7.0)The command I'm using is
cargo fuzzcheck leaderboard::test::fuzz_id_encoding fuzz --artifacts fuzz/artifacts
(leaderboard::test::fuzz_id_encoding
is the path to the test)