-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Clang toolchain from 18.0.0 to 18.1.8 #12365
Conversation
This is rather a draft for discussion and testing : what is the good way to test that ? |
Not sure about authorship, but personally, I think it would be easier to follow the history, if you just took the commit 6defef2 from the other pull request. You can then rebase it on master, or just create a merge commit with master (my preference, because it leaves the commit ID exactly intact). (Edit: Or if you want to keep the pins for now, it'd probably be commit ID 8b26362) This will also include other useful changes, like unpinning the projects that no longer need the pin. For testing, you can test locally (probably only works for a few spot tests), or wait for an admin to create the global infra build. |
171b315
to
dd7bf2b
Compare
Yes, cherry-picking the commits from Alex :-)
I am not sure I want to do that now : I want the least changes possible, only ones in infra, not ones in individual projects : This way, if this patch is good, there should be no changes in the builds status... |
Would be nice to get an infra build here, to see if there are any build issues or other issues |
Should I do something ? |
I think only repo admins can trigger the infra trial-build |
/gcbrun trial_build.py all |
@DonggeLiu what is the outcome of the trial build ? |
What is going on here ? |
Thanks @maflcko. This is the full log. I also noticed many failures. |
@oliverchang, not sure if this is a known issue: Before we fix the bug, we should run the command after 6 PM (Syndey), given that the report was generated after 5 PM: |
@DonggeLiu will you run the command again with the good timing ? |
Sure, I will do it in the afternoon (hopefully I can still remember this). |
/gcbrun trial_build.py all |
It looks like most of the failures are due to the branch being outdated. Before a trial-build, my recommendation would be to merge the current |
/gcbrun trial_build.py all |
Looked already pretty good, did it not ? |
Here is the trial build log log. I (or someone else) will take a look into them |
I looked at the result and I think some projects break due to the compiler bump. It would be good to pin them, or otherwise fix them. https://github.com/google/oss-fuzz/pull/12365/checks?check_run_id=29667299742 trial-buildRemaining builds: 31/1011, defaultdict(<class 'list'>, {'bitcoin-core': ['e97dac9b-220c-45ee-8343-84e9eec6bfe1'], 'bluez': ['b1499b2f-148a-4a43-af5e-084863c2c8a9'], 'checkstyle': ['8d87523f-7b24-473e-af3a-3bdcd241c6ee'], 'cloud-custodian': ['e38a48e3-419c-4e2b-9dd7-f94f18419a20'], 'cpuinfo': ['54fa5e3d-885d-4a6e-8a77-32fd3b80213b'], 'duckdb': ['b0426bc7-3e54-403b-a847-56ee0cb9a412'], 'ffmpeg': ['ac82d2f0-d7ca-4e70-b08b-b660c9dc2a04'], 'genshi': ['d2f6169b-2ec1-47df-8557-505f95afaa7b'], 'gprof2dot': ['33736e00-d147-4d0d-b2d8-7b9f7b78e833'], 'hikaricp': ['0958c36c-12ab-4ecb-9816-19b5e45cfd10'], 'htslib': ['61e7a9d0-2b54-4d1e-a96e-e072703a63f8'], 'http-parser': ['7dc60deb-9c57-4d76-825d-5ed27c6e6d74'], 'imagemagick': ['4075bbc0-1eb4-443a-b141-828a5cea34fe'], 'jq': ['f997d55a-3b45-46ab-b6aa-7f1b8a0888ab'], 'libreoffice': ['021c4098-7db3-49a5-ade8-535674b6fa3d'], 'libxslt': ['2f7b1a83-51da-4096-a39a-5216ee44b14e'], 'libyal': ['c4323b37-191e-4289-bc75-3b3c41a7ec79'], 'muparser': ['7fd96760-4d21-44a5-ae01-cf24e3af2a60'], 'neomutt': ['ab316d4f-3f3b-44cf-a37e-2c7ce2e0a3fb'], 'onednn': ['e6448e28-040b-445b-a7aa-9e8fdb06e382'], 'openweave': ['72af842b-1ce3-45f8-b8d5-3b1202183974'], 'python-phonenumbers': ['229da2ce-22f8-4c23-a3f3-e5fda4a17b1e'], 'simd': ['0d3301bd-6bc7-461c-8722-9fa3ae920b8a', '50e5284d-c067-4800-b6fc-a66b0641243a'], 'spring-cloud-config': ['d6f33c33-d6dd-4e0c-8011-1047e1f9be71'], 'sqlalchemy_jsonfield': ['c2b8ae95-517c-4152-ae49-9bae934a762e'], 'toolbelt': ['f71f41d6-59ec-4744-9dc7-e4656c7819ef'], 'vorbis': ['7a26d044-8d1d-4b68-9327-edb71f387ef3'], 'xmlpull': ['c72c9058-a0f0-408f-98cc-5a68d2b5150d'], 'yoga': ['2ef90f49-a3f6-4036-b0d5-6f00e465cfa3'], 'zopfli': ['10bee761-eaa3-4727-974b-9315b59786f0'], 'llvm': ['5346b641-4627-48a2-aa21-cdf3b33cca3b']}). Failed builds: 20/1011, {'digest': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-5c036d8c-df26-4e9a-969e-7d27732dfabd.txt', 'envoy': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-83da7326-36bd-4815-8b20-9d82e7c8a835.txt', 'freeimage': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-f4924f02-f678-42ef-8ed0-fa4bb18b0a20.txt', 'icu': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-d3be9614-1509-4810-b773-9c35e0e96dd6.txt', 'librawspeed': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-5fe6a7e2-b46e-448a-9311-2ffcc0b6ebdd.txt', 'libucl': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-30f3ad71-bc3d-4dae-8911-9ceb3bf12419.txt', 'libxml2': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-10217692-bb75-406a-bbce-d435640edca9.txt', 'mpv': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-f984eedc-e3ce-4b9f-b2f5-53b747934da7.txt', 'poppler': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-e6a3174b-909c-4366-8c72-099891c22ac1.txt', 'rust-lexical': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-0c261bf2-5504-4713-93e3-ace2b1ebd28d.txt', 'samba': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-9a18541d-f5ba-41f4-9c11-598898d7c031.txt', 'simdutf': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-585902f9-5450-4116-98e0-f3cb912601de.txt', 'suricata': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-c052834b-b700-4c1a-a9c0-b89cd6f3e55a.txt', 'tinyusb': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-879a3840-ccf1-46b8-b971-c835f148a2b9.txt', 'tomlkit': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-37bae839-f8d6-4926-9ea6-d631ef7783fd.txt', 'wasmer': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-01ef123a-b856-4160-b1d0-a7d89f1980ec.txt', 'zeek': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-419c1eb0-b3ab-4cfd-8061-90318e48dec2.txt', 'hadoop': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-36e1962a-7afe-4fa3-bc2d-61dcc4c4c8c3.txt', 'lua': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-702d8ef7-e4fa-4d25-9f47-ca8eb16fea79.txt', 'tarantool': 'https://oss-fuzz-gcb-logs.storage.googleapis.com/log-92a46fa2-369e-4d65-91cd-f4124401c28d.txt' } |
First analysis :
I guess the new warnings need to be fixed by each project Only 2 out of the 7 first failures (icu and libucl) I do not understand and they may be due to this PR. |
Sometimes the project starts to fail to build at the same time the infra run is scheduled. So it may or may not be related to the PR and another build has to be done in those cases (either locally, or in another infra run). If the project is failing, I think maintainers prefer it to be pinned or fixed. Pinning can be achieved similar to commit 767c7d3. (You'll have to adjust the sha256 to be a recent one). |
mpv : centipede again... |
tomlkit: network error ? |
try to make it more clear which changes are needed for which version
177e875
to
4066c8c
Compare
By the way, I also see that log4j2, pcre2 had recent changes in master |
@jonathanmetzman what do you think about this PR ? |
merge on monday if this passes except for arm |
/gcbrun trial_build.py apache-commons-lang arrow-java cert-manager cyclonedds elfutils libxml2 monero pcre2 s2geometry simdutf tinyusb util-linux log4j2 rust-coreutils lua tarantool |
Looks good :-) |
@jonathanmetzman will you merge today ? |
FROM gcr.io/oss-fuzz-base/base-builder | ||
FROM gcr.io/oss-fuzz-base/base-builder@sha256:56905c98ae0083d14da0e7371184e694560a74750533f321ac0e9145af0e8d2e | ||
# ! This project was pinned after a clang bump. Please remove the pin, Try to fix any build warnings and errors, as well as runtime errors | ||
# see https://github.com/google/oss-fuzz/pull/12365 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it's the best way to notify projects. Though given that the latest build failure wasn't reported and the primary contact pointing to the elfutils mailing doesn't seem to work anymore bug reports are likely to go unnoticed as well.
Either way elftuils is built with clang version 18.1.8 (Fedora 18.1.8-1.fc40)
shipped by Fedora just fine. Could it be that something else is broken in the OSS-Fuzz images? The backtrace I saw points to #include <iostream>
and that's weird.
I opened #12550 to trigger the CI but it doesn't look like the base-builder image has been updated yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it's the best way to notify projects
Me neither, but that was asked instead of letting the projects fail because of warnings or such...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that was asked instead of letting the projects fail because of warnings or such
I agree that it's better than the alternatives.
Now that the image is rolled out it looks like the failure is flaky:
https://github.com/google/oss-fuzz/actions/runs/11145617408 (where the coverage build failed)
https://github.com/google/oss-fuzz/actions/runs/11145449506 (where the coverage and UBSan builds failed)
I reproduced it more or less reliably in https://github.com/google/oss-fuzz/actions/runs/11146061465 (where all the relevant builds failed) by removing -j
from make
. The backtrace seems to point to #include <iostream>
and I'm not sure why yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm 99% sure that it's an OSS-Fuzz toolchain bug. I was curious where stack
came from and it turns out it's from src/.deps/srcfiles.Tpo
(which is used when srcfiles.cxx
is compiled):
$ grep stack src/.deps/srcfiles.Tpo
/usr/local/bin/../include/c++/v1/deque stack \
stack:
and it should probably be /usr/local/bin/../include/c++/v1/stack
. I'm guessing elfutils
is unlucky in that it has the stack
binary (which is rejected with all those UTF-8 warnings because it is a binary).
srcfiles.cxx started failing to compile with the OSS-Fuzz toolchain when it was switched from clang-18.0.0 to clang-18.1.8 in google#12365. google#12365 (comment) It's probably an OSS-Fuzz toolchain bug but it doesn't matter much because the srcfiles binary isn't relevant in terms of fuzzing and can safely be excluded.
* [elfutils] unpin the base-builder image * [elfutils] show clang version to make it a bit easier to figure out what's going on. * [elfutils] no longer compile srcfiles.cxx srcfiles.cxx started failing to compile with the OSS-Fuzz toolchain when it was switched from clang-18.0.0 to clang-18.1.8 in #12365. #12365 (comment) It's probably an OSS-Fuzz toolchain bug but it doesn't matter much because the srcfiles binary isn't relevant in terms of fuzzing and can safely be excluded.
Following #12365 : only zeek and opencv seem fixed Co-authored-by: Alex Crichton <[email protected]>
@FrankYFTang for your information, with recent clang bump, icu had centipede disabled. You can try to reenable it |
@Alexhuszagh with recent clang and rust bump, rust-lexical is pinned to an old builder, will you try to fix it ? |
@manunio with recent clang and rust bump, wasmer uses an old nightly (because of dead code warnings with nightly-2024-07-12), would you try to fix them ? |
Thanks for the ping, I will look into it. |
This unpins the image for `rust-lexical`, due to patches in the fuzz targets Cargo.toml to remove LTO from the release profile. Related to: - Alexhuszagh/rust-lexical/issues/164 - Alexhuszagh/rust-lexical/issues/166 - #12365
Follow-up on #12077 by @alexcrichton cc @maflcko
Main difference is to update infra/base-images/base-runner/profraw_update.py so that oss-fuzz converts profraw version 8 to 9 (and llvm-cov seems more tolerant in older version reading cf llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp
This way, it should be more transparent for projects, that can be updated individually or not