myxce/.wolf/bugs/bug-1893.md

id	status	status_updated	status_note	component	severity	timestamp	last_seen	occurrences	files	tags	related	fix_commits
bug-1893	fixed	2026-09-30		scheduler	wrong-result	2026-09-30T03:58:52Z	2026-09-30T03:58:52Z	1	src/scheduler/src/plugins/seqjob_allocator.c src/scheduler/src/plugins/parjob_allocator.c	scheduler allocation preason code-review	bug-1892	d9ef9830 239bcf95 65679285

bug-1893: xce_scheduler allocators never record shared-resource pend reasons (vget rc check inverted)

Description

Observed: found by code reading, so there is no failing run yet. When the shared-resource check fails, both allocators add the pend reasons with

for (i = 0; i < ctx->alloc_req.shared.count; i++) {
    rc = vget(core->resmgr, ((int*)ctx->unmeet.idxs.data)[i], (void**)&r);
    if (rc <= 0) continue;
    add_job_preason(reason->reasons, PREASON_NO_RESOURCE, NULL, r->name);
}

(seqjob_allocator.c my_alloc, parjob_allocator.c my_alloc). The loop bound is the number of requested shared resources, but ctx->unmeet holds only the unmet ones, packed at [0, unmeet.count) by unsatisfy_() (resource.c:152-165). Its arrays were calloced with capacity shared.count (resource.c:280), so entries [unmeet.count, shared.count) are 0.

Expected: iterate i < ctx->unmeet.count (as the host path does, resource.c:566), giving one NO_RESOURCE reason per unmet shared resource.

Impact: wrong pend reason, noise level. When a job requests N shared resources and only M < N are unmet, the loop adds N - M extra PREASON_NO_RESOURCE reasons naming whatever resource has index 0 (if one exists), which that job may never have requested. Main reason and allocation decision are unaffected. No out-of-bounds memory access (the tail is inside the allocation).

Found by: review of the scheduler-allocator-runner requirements (2026-09-29); the loop moves into the framework runner in that spec.

UPDATE (2026-09-30): Found in scheduler-allocator-runner task 2.1 (characterization test test_seqjob_pending_on_short_shared_no_reason_today): the observable effect is not an extra resource-0 reason. vget() (xzarray_get_vec, src/lib/zarray.c) returns 0 on success, and the loop skips on rc <= 0, so it skips every successful lookup and NO shared NO_RESOURCE reason is ever recorded; the over-read tail entries (idx 0) are skipped the same way. Real impact: a job pending on a short shared resource carries no resource reason naming it (main_reason stays 0). The host path (resource.c) correctly skips only rc < 0.

Environment

• OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
• libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
• Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
• Build: asan (xce.build)
• Code: scheduler-framework @ a370d724-dirty
• Deployment: n/a: found by code reading; any deployment where a job requests 2+ shared resources and only some are short

Reproduction

1. git checkout a370d724; read the loop in src/scheduler/src/plugins/seqjob_allocator.c / parjob_allocator.c my_alloc() (after sched_check_shared_satisfy), and src/scheduler/src/resource.c:130-169,266-316.
2. Unit-test sketch: resource idx 0 = slots; two shared resources A (idx 7, plenty) and B (idx 8, total 0); a seqjob primary requesting 1 of each. Expected: exactly one host-less reason (NO_RESOURCE, res "B"); today a second reason names slots.

• Frequency: deterministic (by code reading; no test exercises it yet)
• Evidence: not kept (code reading only)

Root cause

Both allocators' my_alloc() shared-reason loop skipped on vget() <= 0, but vget() (xzarray_get_vec, src/lib/zarray.c) returns 0 on success, so every successful lookup was skipped and no shared PREASON_NO_RESOURCE reason was ever added. The loop also ran to ctx->alloc_req.shared.count instead of ctx->unmeet.count (the tail entries were zero-filled and skipped the same way).

Fix

Allocation moved into the framework runner (spec scheduler-allocator-runner). sched_alloc_prepare_shared_() in src/scheduler/src/alloc_runner.c loops over ctx->unmeet.count and skips only on vget() < 0, adding one host-less NO_RESOURCE reason per unmet shared resource. parjob (task 4.1) and seqjob (task 4.2) now allocate through it; both private loops are deleted.

Verification

• Test: test_shared_short_one_reason_per_unmet_entry (testsuite/test_alloc_runner.c) RED under an rc <= 0 skip ("Expected 1 Was 0"), GREEN after; characterization test_parjob_pending_on_short_shared_names_short_one and test_seqjob_pending_on_short_shared_names_it RED against the old plugins ("Expected 1 Was 0"), GREEN after the switch.
• Suites: scheduler ASAN suite 96/96 (bash src/tools/xce-build.sh scheduler asan build.alloc --jobs 12), 2026-09-30.
• Live: n/a (pend-reason content only; main_reason, decisions, unsatisfiable cache and sim parity unaffected).

References

• Related: none