tests/charm++/objloads: per-PE busy-versus-objects check fails intermittently on the macOS CI runner (2 processes)

Open
  • Is something wrong?
#4,204 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp, macos
Domain
distributed-systems, testing

Research direction

Start with tests/charm++/objloads/client.C and inspect the per-PE busy-versus-object-load check after the element comparison. Reproduce the intermittent failure in the macOS two-process CI step, then compare the check’s behavior with the suggested tolerance or report-only options. Done means the check handles runner contention as intended while retaining the per-element comparison.

Written by the indexing model from the issue text.

Description

tests/charm++/objloads (in the suite since #4182) fails intermittently in the macOS CI job's two-process step. Its client (client.C, the per-PE check after the element comparison) requires each PE's busy time (elapsed minus idle) to be within 10% of elapsed plus 50 ms of the sum of its objects' loads, and on the shared macOS runner the two differ by more than the tolerance.

Seen twice in three days, both on PRs that do not touch tracing or load balancing:

PR job PE busy (s) objects (s) allowed difference (s)
#4186 2026-11-07, reconverse-darwin-arm64 0 1.910 1.642 0.245
#4180 129408450321, 2026-11-09 0 1.152 0.742 0.202
#4180 129408450321 1 1.165 0.841 0.202

Both passed on rerun (#4186) or are being rerun (#4180). The per-element comparison in the same run passes (largest difference 0.0108 s); only the per-PE busy-versus-objects check fails. Busy time also counts runtime work outside any object (communication progress, tracing, the second process competing for the runner's cores), which grows when the runner is loaded.

Possible fixes: make the per-PE check report-only on macOS or under TESTRUN_PROCS, or allow a larger share of elapsed time (the failures needed differences of 14% to 27% of elapsed time) when more than one process shares the machine.

🤖 Generated with Claude Code

Dominant language
C++
Stars
241
Forks
62
Avg merge
1d 1h
Merged PRs (30d)
121

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 charmplusplus/charm

All issues in charmplusplus/charm

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.