Add a valgrind CI leg

[martinus]

Adds one matrix entry: Linux Valgrind (gcc, C++17, 64bit).

What it buys that the existing legs do not

A read of memory that was never written. The sanitizer legs do not cover this and cannot:

tool	finds	already here
ASan	out-of-bounds, use-after-free, leaks	yes
UBSan	language-level UB — it is what catches the memset(nullptr) guard in clear_buckets()	yes
MSan	uninitialised reads	no, and impractical: it needs the whole standard library rebuilt instrumented
valgrind	uninitialised reads, plus leaks	this PR

That gap is worth closing for this container in particular. Buckets are memset rather than constructed, and m_shifts / m_bucket_mask / m_max_bucket_capacity are written by hand in an order chosen so nothing describing the bucket array is published before the array exists — see the comment in allocate_buckets_from_shift. "Has that field been written yet" is a real question to be able to ask.

It finds nothing today, and that is the expected result

Running it against the current tree, with flags stricter than the leg uses:

in use at exit: 0 bytes in 0 blocks
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The code already passes ASan, UBSan, TSan and four fuzzers, so anything in the overlapping categories was gone before this leg existed. The only category where valgrind could have found something new is uninitialised reads, and there are none. The value is prospective — it is a ratchet, not a discovery, and it can only go red on a new uninitialised read or leak.

Verified in both directions

A leg that cannot fail is worth nothing:

• Passes clean — 599 cases, 5.38M assertions, running the exact command the workflow runs.
• Goes red on a real fault — with an uninitialised read planted behind a [[gnu::noinline]] call, valgrind reports Conditional jump or move depends on uninitialised value(s) and meson reports Fail: 1.

Worth noting from the second check: the obvious spelling of an uninitialised read is rejected at compile time by -Werror=uninitialized, so the plant had to be opaque enough to get past the compiler. That is itself a small argument for the leg — the easy cases are already caught, so what is left for a runtime tool is exactly what the compiler cannot see.

Not sharded, and that was measured rather than assumed

The job's total time invites sharding, and the history here is worth keeping because the obvious reading is wrong.

meson test builds before it tests, so the single step is compile plus run — and a brand-new leg starts with an empty ccache, because the key is the matrix id. So the first run's 145s was mostly a cold compile of ~90 translation units, not valgrind.

I shipped a two-way split to find out, and the result settles it:

shard	test cases	step time
fuzz_api	1	127s
everything else	598	128s

One second apart. The run is the small remainder; the build is the job. Sharding it buys nothing and pays for a second cold cache — the two shards came to 161s and 156s against 145s for the single leg they replaced. Reverted, with the measurement left in the workflow comment so the next person to think "shard it" finds out it was already tried.

Risk

The one thing I could not test locally was the runner's valgrind against the runner's glibc, where a mismatch sometimes produces false positives in optimised libc string routines. CI has now run it — clean.

🤖 Generated with Claude Code