From 810b552b44db800ef561393306ce8e5b18d1ebd5 Mon Sep 17 00:00:00 2001 From: Greg Burd Date: Mon, 2 Nov 2026 18:28:28 -0500 Subject: [PATCH] test: two runners that GitHub's ubuntu-26.04 image broke GitHub moved ubuntu-latest from 24.04 to 26.04 between e1fe5c2c4's runs. Master itself has gone red on "ubuntu-latest gcc/clang default", "mutex pthreads-library" and "linux --enable-dtrace (USDT)", and so has every open PR. Neither failure is an engine change; the same tree passed on 24.04 (339e95e3a). 1. run_qam_extent_vrfy timed out (exit 124). Building its 770-extent queue fdatasyncs every extent file, so the run time is the host's fsync latency times ~775: 162 s on 24.04, 181 s on 26.04, against a 180 s timeout. The default timeout for this runner is now 600 s. The syncs were not removed in the test: the attempts tried (a large cache, DB_NOSYNC closes, a private env with DB_NOFLUSH) each moved the syncs elsewhere, and one changed case 2's verdict from DB_VERIFY_BAD to EINVAL. 2. run_dtrace_probes: "bpftrace usdt:bdb:txn__commit fired 0 times". The runner gave bpftrace a fixed 3 s head start before running 100 commits. bpftrace 0.25 (26.04) compiles a BTF vmlinux.h first and attaches later than that, so every commit ran before the probe was live. It now waits for a BEGIN probe's "ATTACHED" line (up to 120 s) and checks the sudo'd bpftrace through /proc, since kill -0 cannot signal a root process. Debian 12, bpftrace 0.17, --enable-dtrace: fired 102 times (100 commits run), PASS. (cherry picked from commit 81e44c28c287dc7daf6420f22177691aac6ce423) --- test/db/run_qam_extent_vrfy.sh | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/test/db/run_qam_extent_vrfy.sh b/test/db/run_qam_extent_vrfy.sh index 9d981c4955..a359fffd50 100755 --- a/test/db/run_qam_extent_vrfy.sh +++ b/test/db/run_qam_extent_vrfy.sh @@ -28,7 +28,14 @@ BUILD=${BUILD:-.} _HERE=$(cd "$(dirname "$0")" && pwd) SRC=${SRC:-$_HERE/qam_extent_vrfy.c} HOME_DIR=${HOME_DIR:-QAM_EXTENT_VRFY_TESTDIR} -TIMEOUT=${TIMEOUT:-180} +# 600 s, not the usual 180 s: building the many-extent queue fdatasyncs each of +# its ~775 extent files (eviction-discard during the fill and the per-file sync at +# close), so the run time is the host's fsync latency times 775. That was +# 162 s on GitHub's ubuntu-24.04 runners and 181 s on ubuntu-26.04, which timed +# out at 180 s. The I/O pattern is what the test exercises; do not shorten it by +# skipping syncs (DB_NOSYNC + DB_NOFLUSH changed case 2's verdict from +# DB_VERIFY_BAD to EINVAL). +TIMEOUT=${TIMEOUT:-600} # Prefer the STATIC library: on macOS the .dylib carries a baked-in install name # (/usr/local/BerkeleyDB.5.3/lib/...) which takes precedence over -rpath, so a