| id |
status |
status_updated |
status_note |
component |
severity |
timestamp |
last_seen |
occurrences |
files |
tags |
related |
fix_commits |
| bug-1887 |
fixed |
2026-09-29 |
|
lib |
wrong-result |
2026-09-29T09:48:49Z |
2026-09-29T09:48:49Z |
1 |
| src/lib/xce_resreq.peg |
| src/lib/resreq.c |
|
|
|
|
bug-1887: resreq parser ignores a primary's select/rusage parse error and accepts the job without that clause
Description
Observed: (code reading) the primary_resreq action in
src/lib/xce_resreq.peg calls
parse_resreq_primary(primary, $0, auxil->resmgr, &(auxil->errmsg))
and ignores its return value; nothing sets has_error, so
parse_resreq() returns success. A primary whose select or rusage clause
fails to parse is kept without that clause (select NULL / rusages empty),
i.e. the job is scheduled as if it had no such constraint. While fixing
bug-1884 a LeakSanitizer report showed such an error message being
produced during a normal replay fixture (its job's resreq parsed "OK").
Expected: a primary sub-parse error makes parse_resreq() fail with that message (the job is rejected/pended with a parse error), not silently dropped.
Impact: wrong result: a job with a malformed select (e.g. a typo) may dispatch onto hosts its select would have excluded.
Found by: review (while fixing bug-1884, 2026-09-29)
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 (src/xce.build.discrete)
- Code: scheduler-framework @ 90b99d91-dirty
- Deployment: n/a (found by code reading while fixing bug-1884; not observed on a deployment)
Reproduction
- Read the
primary_resreq action in src/lib/xce_resreq.peg and parse_resreq_primary() in src/lib/resreq.c.
- Unit check:
parse_resreq(&r, "select[type==] rusage[mem=1]", resmgr, &err) -- expect rc < 0; observe the return value.
- Frequency: deterministic for any malformed select/rusage inside a primary
- Evidence: not kept; LeakSanitizer stack from the bug-1884 fixture (strdup in parse_select error path under core_build_job)
Root cause
The primary_resreq action in src/lib/xce_resreq.peg ignored parse_resreq_primary()'s result and nothing set has_error, so parse_resreq() succeeded for a primary whose select/rusage clause failed to parse and the job kept no such clause. Confirmed with a probe (2026-09-29): select[type==], select[mem>], select[type==any && ] all returned rc=1 with select NULL; select[gpu>1] with no gpu resource likewise.
Fix
A malformed clause now fails the whole resreq and parse_resreq() returns the clause's own message (b5712c05). A select naming an unregistered resource is still dropped rather than rejected: parse_select() reports it as -ENOENT (new select_context_t.unknown_resource) and the action lets it pass, because jobs rely on it -- the scheduler's own "type == any" default among them when no "type" resource is registered (making it fatal failed 36 scheduler suites). Whether an unknown resource in a select should reject the job is left as a separate decision. Making syntax errors fatal exposed bug-1888.
Verification
- Test: test_resreq_primary_select_error_fails_parse in src/lib/testsuite/test_resreq.c (xkvmgr resmgr with type/mem; syntax errors incl. inside a compound fail with a message; unknown resource still parses with select NULL; valid select kept): RED before (all accepted), GREEN after
- Suites: ASAN debug build (src/xce.build.discrete),
meson test --no-suite xceadmin: 117/117 OK, 0 sanitizer reports; xcelib_test 695 tests 0 failures (2026-09-29)
- Live: 3-round sequential HA soak on rebuilt ASAN binaries (/home/claude/tmp/xce-bug1885-soak, 2026-09-29): PASS, 15 jobs, zero job loss, all 3 nodes led; SIMVERIFY 4 files 0 mismatches; each recording replays with detect_leaks=1 at exit 0, 0 mismatches; no sanitizer report in the scheduler or controller stderr
References
