59 lines
4 KiB
Markdown
59 lines
4 KiB
Markdown
---
|
|
id: "bug-1886"
|
|
status: "fixed"
|
|
status_updated: "2026-09-29"
|
|
status_note: ""
|
|
component: "scheduler"
|
|
severity: "leak"
|
|
timestamp: "2026-09-29T09:48:47Z"
|
|
last_seen: "2026-09-29T09:48:47Z"
|
|
occurrences: 1
|
|
files: ["src/scheduler/src/scheduler.c", "src/scheduler/src/core_events.c"]
|
|
tags: ["scheduler", "leak", "config"]
|
|
related: ["bug-1884"]
|
|
fix_commits: ["3e873f0a"]
|
|
---
|
|
|
|
# bug-1886: scheduler leaks the rejected queue on each config re-apply and the old config on each CONFIG_PUSH
|
|
|
|
## Description
|
|
**Observed:** (code reading)
|
|
- `sched_init_queues()` (src/scheduler/src/scheduler.c) builds a new
|
|
`xce_sched_queue_t` for every configured queue on each config apply and
|
|
`sched_add_queue()`s it; for an existing name the add fails and the new
|
|
queue (with its interned name/resreq) is still handed to the picker but
|
|
owned by nothing.
|
|
- `CONFIG_PUSH` (core_events.c) sets `core->config = config` without freeing
|
|
the previous config.
|
|
|
|
**Expected:** re-applied queues update the existing queue in place (as `core_upsert_queue()` does for QUEUE_UPDATE), and a replaced config is freed once nothing points into it.
|
|
**Impact:** leak per config push/re-apply (one queue per configured queue plus one whole `xce_conf4sched_t`). Freeing the old config needs care: the picker and limit plugin may keep pointers into it. The queue table's datakiller must stay a no-op for as long as `sched_init_queues()` keeps using a rejected queue (bug-1884 found a use-after-free when it freed).
|
|
**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 `sched_init_queues()` in src/scheduler/src/scheduler.c and the `XCE_CORE_EVENT_CONFIG_PUSH` case in src/scheduler/src/core_events.c.
|
|
2. Test-level check: `test_config_push_deferred.c` applies a config twice; with a freeing queue killer ASAN reports a heap-use-after-free in `builtin_fcfs_on_queue_update` (seen 2026-09-29 while fixing bug-1884).
|
|
- Frequency: deterministic on every config re-apply
|
|
- Evidence: not kept; code reading plus the test_config_push_deferred UAF seen with a freeing killer
|
|
|
|
## Root cause
|
|
`sched_init_queues()` built a new `xce_sched_queue_t` for every configured queue on each config apply; for an existing name `sched_add_queue()` failed and the unregistered queue was handed to the picker (which then tracked it instead of the registered one) and leaked, while the registered queue kept its old settings. `sched_init_config()` and the core's CONFIG_PUSH replaced `core->config` without freeing the previous one.
|
|
|
|
## Fix
|
|
`sched_init_queues()` updates the registered queue in place (attrs, status, priority, accept_interval, sched_delay -- what make_sched_queue() copies), as QUEUE_UPDATE's core_upsert_queue() does; a replaced config is freed after the new one is applied -- nothing points into it (queues, resources, groups and limits built from it are copies) (3e873f0a).
|
|
|
|
## Verification
|
|
- Test: test_config_reapply_updates_queue_in_place_and_frees_old in src/scheduler/testsuite/test_config_push_deferred.c (applies a one-queue config twice, priority 1 then 7): RED before (priority stayed 1), GREEN after (same queue object, priority 7, first config freed per ASAN)
|
|
- 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
|