ci: add Valgrind fuzz

fanquake commented at 9:02 pm on September 22, 2025: member

Valgrind fuzz runtime?

DrahtBot added the label Tests on Sep 22, 2025

DrahtBot commented at 9:02 pm on September 22, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33461.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	dergoegge
Stale ACK	kevkevinpal

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

No conflicts as of last run.

maflcko commented at 8:52 am on September 23, 2025: member

Seems fine to add, and the runtime seems fast. Though, I wonder how many issues this will find. The only issue I am aware of this year is #32121, but this was only found by adding newly generated fuzz inputs to the qa-assets repo, which already runs this CI task.

(Same feedback for #33626, which seems similar, with the difference of added library hardening?)

fanquake force-pushed on Oct 15, 2025

fanquake marked this as ready for review on Oct 15, 2025

fanquake closed this on Oct 21, 2025

dergoegge commented at 4:00 pm on October 21, 2025: member

ACK c020ae082664438cf340cb196fc5bd0d31ed810f

I think it’d be good to have this in CI (for the rare case where it does find something).

fanquake reopened this on Oct 21, 2025

kevkevinpal commented at 4:25 pm on October 21, 2025: contributor

ACK c020ae0

I agree with @dergoegge. Given the fact that it did find an issue, I think it’s worth running.

in .github/workflows/ci.yml:504 in c020ae0826

499@@ -500,6 +500,12 @@ jobs:
500             timeout-minutes: 240
501             file-env: './ci/test/00_setup_env_native_fuzz.sh'
502 
503+          - name: 'Valgrind, fuzz'
504+            cirrus-runner: 'ghcr.io/cirruslabs/ubuntu-runner-amd64:24.04-lg'

maflcko commented at 6:30 am on October 22, 2025:

0            cirrus-runner: 'ghcr.io/cirruslabs/ubuntu-runner-amd64:24.04-md'

Looks like the runtime with lg was 50 minutes. I wonder if it will be the same speed, using md, as there are only three trailing, slow fuzz tests.

fanquake commented at 8:13 am on October 22, 2025:

Dropped to md for a look.

maflcko commented at 9:29 am on October 22, 2025:

Hmm, looks like it was faster, which seems odd

maflcko commented at 6:32 am on October 22, 2025: member

lgtm

Conceptually, the same feedback on valgrind applies here (https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3410475429), but if an issue arises, it should be fine to quickly drop this task again to unblock the CI caused by a false-positive.

ci: add Valgrind fuzz e4b04630bc

fanquake force-pushed on Oct 22, 2025

dergoegge approved

dergoegge commented at 9:53 am on October 22, 2025: member

ACK e4b04630bcf59ea03c1373777a0167af699f92a4

fanquake merged this on Oct 22, 2025

fanquake closed this on Oct 22, 2025

fanquake deleted the branch on Oct 22, 2025

maflcko commented at 1:56 pm on October 23, 2025: member

Just noting that this is now the slowest test on the GitHub runners (outside this repo). With or without the cache, the runtime there seems to be 3h +- 5 minutes (https://github.com/maflcko/bitcoin-core-with-ci/actions/runs/18740251063/job/53473768619)

Not sure if we should aim to be below some runtime, just wanted to mention it could be mildly distracting to have to wait 3h to get a full CI result (and failed notification on error). Fine by me, but not sure if others rely on that CI pipeline outside.

m3dwards commented at 3:15 pm on October 23, 2025: contributor

Not sure if we should aim to be below some runtime

All things being equal of course we would want CI to be quicker than slower and I think it will impact at least my common workflow of waiting for a positive CI workflow on my fork before submitting a PR or change to PR.

Could this be a candidate for more of a nightly job, especially if as mentioned in this PR we expect failures to be rare?

fanquake commented at 3:23 pm on October 23, 2025: member

I don’t think it’s clear that we should trade-off running more tests here (which are fast), when it results in slower total runtime on forks. Shouldn’t we be optimising for more tests run in this repo (given the general workflow is just to open PRs directly to the repo).

ci: add Valgrind fuzz #33461

Code Coverage & Benchmarks

Reviews

Conflicts