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

id	status	status_updated	status_note	component	severity	timestamp	last_seen	occurrences	files	tags	related	fix_commits
bug-1886	fixed	2026-09-29		scheduler	leak	2026-09-29T09:48:47Z	2026-09-29T09:48:47Z	1	src/scheduler/src/scheduler.c src/scheduler/src/core_events.c	scheduler leak config	bug-1884	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