Stream: git-wasmtime

Topic: wasmtime / issue #3563 CI: Add CIFuzz integration

view this post on Zulip Wasmtime GitHub notifications bot (Nov 26 2021 at 19:50):

DavidKorczynski commented on issue #3563:

I can pin it to a specific commit hash if you'd like?

Looks like we're already hitting an issue in CIFuzz actually, and I believe it's related to this line in the log: 

2021-11-26 19:24:49,390 - root - INFO - Running: docker run --rm --privileged -e FUZZING_ENGINE=libfuzzer -e ARCHITECTURE=x86_64 -e CIFUZZ=True -e SANITIZER=address -e FUZZING_LANGUAGE=rust -e OUT=/github/workspace/build-out --volumes-from 82a9e3a32f9d gcr.io/oss-fuzz/wasmtime /bin/bash -c 'cd / && rm -rf /src/wasmtime/* && cp -r /github/workspace/storage/wasmtime /src && cd - && compile'.

Which happens the code of Dockerfile in oss-fuzz has run. I think it's the same as this issue on CIFuzz https://github.com/google/oss-fuzz/issues/6755

view this post on Zulip Wasmtime GitHub notifications bot (Nov 29 2021 at 15:25):

alexcrichton commented on issue #3563:

Thanks for the PR! My main personal question on this is how long it takes in CI since building the fuzzers can take quite some time. We can try to get a successful build first to get that information.

The error on CI to me looks like submodules may not be checked out, and it looks like google/oss-fuzz is in charge of the git checkout process as well so that may be the point of error?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 29 2021 at 15:27):

DavidKorczynski commented on issue #3563:

Thanks for the PR! My main personal question on this is how long it takes in CI since building the fuzzers can take quite some time. We can try to get a successful build first to get that information.

Sounds good, will get that fixed up.

The error on CI to me looks like submodules may not be checked out, and it looks like google/oss-fuzz is in charge of the git checkout process as well so that may be the point of error?

I think the issue is the same as here: https://github.com/google/oss-fuzz/issues/6755

I can fix up the wasmtime Dockerfilein way this should get sorted. Basic idea is to grab all submodules in build.sh rather than Dockerfile on Github. Will do this shortly and ping here when done!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 29 2021 at 20:04):

DavidKorczynski commented on issue #3563:

@alexcrichton I think it should work now - could you trigger the CI to verify?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 29 2021 at 20:07):

alexcrichton commented on issue #3563:

the button has been pushed

view this post on Zulip Wasmtime GitHub notifications bot (Nov 29 2021 at 21:42):

alexcrichton commented on issue #3563:

Ok looks like it worked, but clocks in at just over and hour, which I think is a bit strenuous for our current CI situation unfortunately

view this post on Zulip Wasmtime GitHub notifications bot (Nov 29 2021 at 21:56):

DavidKorczynski commented on issue #3563:

Fair enough, I guess the OSS-Fuzz build time is the heavy hitter (42 min) but am unsure if this can be improved. Most likely it can't be improved to to the point where it fits your CI situation - let's close this PR?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 29 2021 at 23:57):

fitzgen commented on issue #3563:

Yeah just a bit too slow to block PRs on. I think we'll have to accept the latency associated with waiting for the next time oss-fuzz pulls and rebuilds wasmtime.

Thanks for investigating this, though, @DavidKorczynski!

Last updated: Dec 23 2024 at 12:05 UTC