60 lines
4.1 KiB
Markdown
60 lines
4.1 KiB
Markdown
---
|
|
id: "bug-1887"
|
|
status: "fixed"
|
|
status_updated: "2026-09-29"
|
|
status_note: ""
|
|
component: "lib"
|
|
severity: "wrong-result"
|
|
timestamp: "2026-09-29T09:48:49Z"
|
|
last_seen: "2026-09-29T09:48:49Z"
|
|
occurrences: 1
|
|
files: ["src/lib/xce_resreq.peg", "src/lib/resreq.c"]
|
|
tags: ["lib", "resreq", "parser"]
|
|
related: ["bug-1884"]
|
|
fix_commits: ["b5712c05"]
|
|
---
|
|
|
|
# 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
|
|
1. Read the `primary_resreq` action in src/lib/xce_resreq.peg and `parse_resreq_primary()` in src/lib/resreq.c.
|
|
2. 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
|
|
- Related: bug-1884
|