Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

tools, model: two T1 reds on Ubuntu 26.04 with a 16-thread pool

Open
  • Is something wrong?
#52 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
bash, linux, rust
Domain
backend, testing

Research direction

Start with tools/ref/card-tests/cpu-guard.sh:99-101 and crates/model/src/ops.rs:6722, then read crates/threads/src/lib.rs:566,653 and the pool setup at crates/model/src/ops.rs:3905. Run the CPU guard script and the named model test with BLOOMERY_THREADS=16 and 24. Done means both tests pass on the reported Ubuntu/uutils setup and the model test's premise holds across the supported pool sizes.

Written by the indexing model from the issue text.

Description

model tools

just contrib-check --tier t1 on main e8e32a38 ends DONE tier=t1 total=85 red=2 wall=794s red: check-recipes bloomery-model on an AMD Ryzen 9 9950X running Ubuntu 26.04.1. Both come from something the test assumes about the host, and neither failing test gets as far as checking what it is there to check. Both tests are unchanged on main de57867c.

1. cpu-guard: a copy of yes does not run under uutils coreutils

FAIL the cpu guard tests (cpu-guard.sh): rc 1, want 0
    | FAIL live: a foreign busy process tags the row: rc 1, want 0
    |     | coreutils: unknown program 'cargo-foreign'
    |     | bash: line 4: kill: (207486) - No such process
    | cpu-guard: 11 tests, 1 failed

tools/ref/card-tests/cpu-guard.sh:99-101 copies $(command -v yes) to gends41-own and cargo-foreign, so that the processes have those names. On Ubuntu 26.04 coreutils comes from uutils by default (coreutils-from-uutils, rust-coreutils 0.8.0), and /usr/bin/yes is a symlink to one multicall binary that picks the program by argv[0]. A copy under another name prints coreutils: unknown program '<name>' and exits, so there is no busy process to see.

The test before it, "live: the runner's own busy arm does not tag its row", passes for the same reason: gends41-own does not run either, so nothing could have tagged the row. It passes here with no busy process to leave out.

GNU yes is still installed as /usr/bin/gnuyes (package gnu-coreutils), but that name is not on other hosts. A busy loop that does not depend on argv[0], for example a two-line #!/bin/sh script with a while :; do :; done loop written under each name (the kernel sets comm to the script's file name), would run the same on both. With that change in a local copy, bash tools/ref/card-tests/cpu-guard.sh gives cpu-guard: 11 tests, 0 failed here.

2. a_profiled_ccd_dispatch_counts_busy_time_by_participant at a pool of 13 to 16 threads

---- ops::ccd_tests::a_profiled_ccd_dispatch_counts_busy_time_by_participant stdout ----
thread 'ops::ccd_tests::a_profiled_ccd_dispatch_counts_busy_time_by_participant' (238479) panicked at crates/model/src/ops.rs:6722:9:
assertion `left != right` failed: in lane order and in participant order apart
  left: 5
  right: 5

The test builds CcdMap::new(pool.threads(), 4, 0) and takes lane = map.first_lane(1) + 1, the lane of CCD 1's second rank. Its premise is that the participant owning that lane has a different number from the lane. With ccd_slot's rule (crates/threads/src/lib.rs:566; participant t is on CCD t % 4 at rank t / 4), that participant is always 5, and the lane is q + min(1, r) + 1 (first_lane, lib.rs:653) for q, r = threads / 4, threads % 4. The two are equal when q + min(1, r) = 4: 13, 14, 15 and 16 threads.

The pool defaults to the physical core count, which is 16 on a 9950X, so the test fails here with no lever set. With BLOOMERY_THREADS=24 and BLOOMERY_THREADS=32 it passes. The test's own assert asks for 8 or more threads. CCD 1's first rank would keep the premise at every such pool: its lane is map.first_lane(1) = q + min(1, r), at least 2 from 8 threads up, and its participant is always 1. A fixed thread count for this test alone would not work, because the map has to name the pool's participants (ops.rs:3905) and the pool is built once per process.

Setup

  • AMD Ryzen 9 9950X (16 cores, 32 threads), 64 GB. Ubuntu 26.04.1, Linux 7.0.0-38-generic, rust-coreutils 0.8.0-0ubuntu3 as the default coreutils.
  • nightly-2026-08-28 (RUSTFLAGS: -C target-cpu=native, as contrib-check sets it on x86_64), CUDA 13.3 (nvcc 13.3.73), LLVM 21.1.8.
  • Run under LC_ALL=C, because the lease self-test's strerror case fails under a Korean locale (noted in #38).
LC_ALL=C just contrib-check --tier t1
BLOOMERY_THREADS=16 cargo test --release -p bloomery-model --lib ops::ccd_tests::a_profiled_ccd_dispatch_counts_busy_time_by_participant
BLOOMERY_THREADS=24 cargo test --release -p bloomery-model --lib ops::ccd_tests::a_profiled_ccd_dispatch_counts_busy_time_by_participant

이슈 보고일 뿐 따로 PR을 게시할 계획은 현재 없습니다.

Dominant language
Rust
Stars
21
Forks
4
Avg merge
4h 8m
Merged PRs (30d)
77

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from midagedev/bloomery

All issues in midagedev/bloomery

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.