-
Notifications
You must be signed in to change notification settings - Fork 2.4k
opensk: do not specify nightly #6648
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
so that coverage works because we use the cargo wrapper which looks for fuzz build argument at the beginning
@kaczmarczyck |
When I try to reproduce locally, I don't see a difference between adding nightly or not. As for the actual problem, I didn't get to the root of it yet. |
Oh, or with "wrong", you don't mean for reproducing my bug, but for the failing test? |
Indeed, "wrong" means this PR breaks the regular fuzzing builds, even if it fixes the coverage ones |
I had a look and it seems that local and docker builds all work, only the GitHub workflow is affected? I'd have to dig deeper into the OSS-Fuzz setup to understand the differences here. |
I get the error locally.
This gives me the error |
Ah I see. For the --- a/projects/opensk/build.sh
+++ b/projects/opensk/build.sh
@@ -19,7 +19,10 @@ FUZZ_TARGET_OUTPUT_DIR=fuzz/target/x86_64-unknown-linux-gnu/release
build_and_copy() {
pushd "$1"
- cargo fuzz build --release --debug-assertions
+ rustup toolchain install nightly-2021-10-01
+ cargo +nightly-2021-10-01 fuzz build --release --debug-assertions
for f in fuzz/fuzz_targets/*.rs
do
cp ${FUZZ_TARGET_OUTPUT_DIR}/$(basename ${f%.*}) $OUT/ but changing the channel to I don't have time to look into LLVM version support in oss-fuzz, but thanks for your help so far! |
Thanks, I think I got the problem. |
The build failures just resolved: |
so that coverage works because we use the cargo wrapper
which looks for fuzz build argument at the beginning
cc @kaczmarczyck