Open alexcrichton opened 2 weeks ago
@maflcko you mentioned in https://github.com/google/oss-fuzz/issues/11626 that before doing this all existing projects should be un-pinned from their @sha256...
pins. Is that required to bump Clang? I would have expected the other way around where some new projects might need pinning as a result of this.
Also, do you know of a way to more easily enumerate the projects which break as a result of this upate? I probably can't feasibly build everything locally. If CI takes care of this though I can also just wait for that.
Also, for reference, I've confirmed that by layering #12075 on top of this Rust projects no longer have any warnings in coverage builds and coverage looks like it might work.
Also, following up from your comment here you mentioned that pinned projects might break since they're using clang 15. I think though that the decoding of coverage data supports older versions, just not newer versions, so my assumption would be that LLVM 18 tooling would be able to decode clang 15-generated coverage information. I don't have data to back up this assumption, however.
/gcbrun trial_build.py all
Is that required to bump Clang?
Yes, because the coverage container uses the current llvm to parse the coverage profile (regardless of what the project uses), but if the profile was generated with llvm-15 (pinned projects) it will fail.
It should be possible to observe this in the trial build.
LLVM 18 tooling would be able to decode clang 15-generated coverage information
In theory, yes, earlier coverage profiles can be read. However, the raw profile version is a separate versioning, and a breaking change every time, as far as I understood it.
For reference, the trial build result is https://github.com/google/oss-fuzz/pull/12077/checks?check_run_id=26334505585:
Thanks for the links! I'll start reviewing those hopefully soon.
Also I was having a tough time understanding what you were referring to before about LLVM 15 breaking. I thought that because the current coverage container was using LLVM 18 that updating it to LLVM 18.1 wouldn't be an issue because it would already be broken with LLVM 15 coverage information. Upon checking though it looks like the version in the LLVM source for profiling was "8" both with LLVM 15 and LLVM 18.0.0. The first change happened with LLVM 18.1 so that also makes more sense to me.
I'll try to dig in further to the failure logs and see what the impact of this is. Also I'll note I'm happy to rebase around other changes, so please don't block on me for anything.
The failures should all be related to the raw coverage profile version in some way or another. I don't see another way other than to atomically and globally bump the coverage version for all projects and all languages. But that requires the projects to be un-pinned, and a rust-nightly bump to be combined into this pull.
My recommendation would be to change https://github.com/google/oss-fuzz/pull/12075 to nightly-2024-02-12 for now, then wait for it to land and then bump 2024-02-12
to the current date as part of this pull request.
Ok I've gone through many of the failures and I'm sort of quite new to updating the toolchain here so I wanted to ask a few questions. I've tried to bucket all the various failure logs into a few categories:
error: no type named 'remove_all' in namespace 'std::filesystem'
)@sha256:...
pins all failed due to profiling version mismatches.My main question is how to handle most of these. Two action items for this PR are to update Rust in this PR and update Swift as well. Everything else though I'm less certain about. For example resolving new Clang errors will require source changes. I tested a few of the @sha256:...
pinned builds and I presume they're pinned because they succeeded with Clang 15 and failed when Clang was updated to 18, and I can at least confirm they're still failing with Clang 18.1.7 as well. Should I pin all the new failures to the Clang 18 builder so the fuzzers at least still build even if coverage information is broken?
There's still other failures I don't fully understand which I'm not sure if y'all would recognize or not
Oh and one final category of failures I forgot to mention are those that failed to build but also failed to build according to their latest status, so I ignored a few builds like that.
Some arm64-related errors happened but I couldn't make heads or tails of them
They are expected, I think, and can be ignored for now, because the infra check does not spin up arm64 machines.
You can use curl 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-ca500d39-e7d6-4fdc-b24e-0d507b9c8674.txt' | tail -111
to see the tail of the (large) log only. It is the arm failure.
Two projects failed with coverage mismatches in a way I didn't understand. These weren't pinned to older containers but they also both have a custom corpus, so I don't know if that factors in here
You will have to rebase or merge with master before the trial build. Otherwise the changes (2c03690aa3849276fc00b7dff85cfb3c4b99456f) aren't picked up.
If more than one project is affected by a build warning, you can soften it. For example:
diff --git a/infra/base-images/base-clang/Dockerfile b/infra/base-images/base-clang/Dockerfile
index f61b85443..c82ed1008 100644
--- a/infra/base-images/base-clang/Dockerfile
+++ b/infra/base-images/base-clang/Dockerfile
@@ -58,9 +58,9 @@ ENV CCC "clang++"
# The implicit-function-declaration and implicit-int errors are downgraded to a
# warning, to allow compiling legacy code.
# See https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes
-# Same for deprecated-declarations, int-conversion,
+# Same for vla-cxx-extension, deprecated-declarations, int-conversion,
# incompatible-function-pointer-types, enum-constexpr-conversion
-ENV CFLAGS "-O1 -fno-omit-frame-pointer -gline-tables-only -Wno-error=enum-constexpr-conversion -Wno-error=incompatible-function-pointer-types -Wno-error=int-conversion -Wno-error=deprecated-declarations -Wno-error=implicit-function-declaration -Wno-error=implicit-int -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION"
+ENV CFLAGS "-O1 -fno-omit-frame-pointer -gline-tables-only -Wno-error=enum-constexpr-conversion -Wno-error=incompatible-function-pointer-types -Wno-error=int-conversion -Wno-error=deprecated-declarations -Wno-error=vla-cxx-extension -Wno-error=implicit-function-declaration -Wno-error=implicit-int -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION"
ENV CXXFLAGS_EXTRA "-stdlib=libc++"
ENV CXXFLAGS "$CFLAGS $CXXFLAGS_EXTRA"
Swift-based builds all looked to fail - I think this means that the Swift compiler needs to be updated to LLVM 18.1+ as well
Looks like Swift 5.8.1 is currently used which uses LLVM 13.0.0. The latest release of Swift is 5.10.1 which comes with LLVM 15.0.0. It looks like Swift 6 is in development but I wasn't able to find a binary to download and see if it's at the right version.
Given that I don't think there's an easy fix for Swift for now.
/gcbrun trial_build.py all
From the trial build I've categorized the failures into:
Given this categorization the open questions I would have are:
@sha256
pins of containers? Some will start failing to build but they're all guaranteed to have bad coverage information. Or should I add @sha256
pins for builds that are broken by this update?-Wno-error=format-truncation
from this PR for example and would leave libphonenumber
broken. (this question is less relevant if @sha256
pins are added)Should I remove all
@sha256
pins of containers? Some will start failing to build but they're all guaranteed to have bad coverage information. Or should I add@sha256
pins for builds that are broken by this update?
I am working on unpinning them, but it will take some time.
See https://github.com/google/oss-fuzz/pulls?q=is%3Aopen+is%3Apr+author%3Amaflcko+%22Use+latest+builder%22 for the current progress.
But yeah, I'd say to remove the pin of all projects here. This will fix a few projects, like https://github.com/google/oss-fuzz/pull/12128#issuecomment-2192485399. A few will remain broken, but those can be handled later/separately.
Also, make sure to rebase again to pick up d63f82f8e202bfa7207b562dce034927d3e6f94f.
Sounds good, I've rebased, removed the one-off warning flag allowances, and removed @sha256:...
pins
Only envoy/samba needed new flags, looks like the other projects have updated in the meantime and no longer need a fix
Do we need another trial build here?
A trial build can't hurt, but I'd say that the outstanding fixes, like https://github.com/google/oss-fuzz/pull/12096 should be merged first, then this pull request should be merged or rebased with master to pick up all fixes, then a trial build should be done.
A trial build can't hurt, but I'd say that the outstanding fixes, like #12096 should be merged first, then this pull request should be merged or rebased with master to pick up all fixes, then a trial build should be done.
OK. Let me know when this is ready for another please
This is done in the interest of assisting #12075 and #11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.7 and coverage information breaks. This breakage is because LLVM 18.1.7 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8".
This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.