---
id: "bug-1884"
status: "partial"
status_updated: "2026-09-29"
status_note: "part 1 (9b61fd99): sim teardown + core registries, 17.2 MB -> 75 KB at exit; part 2: replay-event payload release, core->config, job/resource destructors, snapshot-load data"
component: "scheduler"
severity: "leak"
timestamp: "2026-09-29T08:20:03Z"
last_seen: "2026-09-29T08:20:03Z"
occurrences: 1
files: ["src/scheduler/src/sim_loop.c", "src/scheduler/src/sim.c", "src/scheduler/src/plugins/limit.c", "src/scheduler/src/main.c"]
tags: ["scheduler", "sim", "asan", "lsan", "leak"]
related: ["bug-1632", "bug-1763"]
gitea_issue: 335
gitea_synced_status: "open"
gitea_synced_hash: "097b7ddb90dd"
---

# bug-1884: standalone ASAN xce_scheduler --sim exits 1: LeakSanitizer reports 17 MB still allocated at exit

## Description
**Observed:** an ASAN build of `xce_scheduler --sim=<file> --sim-verify`
replays the whole recording (0 MISMATCH lines) and then exits 1 because
LeakSanitizer reports at exit:
```
==2234882==ERROR: LeakSanitizer: detected memory leaks
...
SUMMARY: AddressSanitizer: 17041405 byte(s) leaked in 1187 allocation(s).
```
Of the 17,041,405 bytes, 17,036,261 are indirect and 5,144 direct.
Grouped by first scheduler/lib frame (bytes, leak groups):
- `kvtab_init` (lib/kv.c:106): 16,941,432 in 15 -- core kv tables, reachable only from leaked roots
- `sim_process_replay_event_message` (sim_loop.c:403): 49,688 in 54 -- decoded replay events (e.g. `decode_JobStateChangeEvent_ptr`)
- `xkvmgr_add` (lib/kvmgr.c:114): 21,376 in 9
- `sim_locate_and_load_snapshot` (sim.c:224): 14,347 in 106 -- snapshot decode (`decode_Conf4Sched` / `decode_QueueConf_list`)
- `put_resvals` (resource.c:99) via limit.c `update_limit_res_value` and `sched_update_res_accounts`: 2,048 in 2
- smaller: `parse_resreq`, `core_build_job`, `sched_ctx_init`, `match_job_host_limit_`

The indirect bulk fits the simulator never tearing down its core at exit
(its picker/allocator threads are never joined, see bug-1632/bug-1763);
the direct groups may include real per-event leaks.

**Expected:** a clean replay exits 0 under ASAN with LeakSanitizer enabled,
or the exit-time teardown frees what the driver owns.
**Impact:** leak; for scripts, any ASAN `--sim` replay must set
`ASAN_OPTIONS=detect_leaks=0` or its exit code is always 1, which masks real
failures and hides any genuine per-event leak among the exit-time noise.
Release builds are unaffected at exit; a per-event leak would still grow a
long replay's memory.
**Found by:** spec task (libxce-alloc-preason-equality 5.3, live
default-settings replay, 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, debug + b_sanitize=address)
- Code: scheduler-framework @ 4500ec46-dirty
- Deployment: n/a (standalone simulation mode, no cluster); the replay file was recorded by a local 3-node HA soak (run-ha-soak.sh, 2 sequential rounds, xcecd_virtual worker) at /home/claude/tmp/xce-alloceq-53

## Reproduction
1. `bash src/tools/xce-build.sh scheduler asan` (or any ASAN build dir)
2. `src/xce.build/scheduler/xce_scheduler --sim=/home/claude/tmp/bug-1884/scheduler-replay-20260929-064412.replay --sim-verify --logfile /tmp/sim.log; echo rc=$?`
3. Observe `rc=1` and the LeakSanitizer SUMMARY on stderr. With `ASAN_OPTIONS=detect_leaks=0` the same run exits 0.
- Frequency: deterministic (2/2 runs, identical totals, 2026-09-29); also seen on every recording of /home/claude/tmp/xce-ha-dc-soak
- Evidence: /home/claude/tmp/bug-1884/lsan-report.txt (full report), /home/claude/tmp/bug-1884/scheduler-replay-20260929-064412.replay

## Root cause
Nothing tears the simulator down: sched_sim_driver_run() never joined its
picker/allocator threads and main() exited without finalizing the core. On
top of that, several ownership gaps only show once teardown runs:
- xce_sched_core_fini() never destroyed the plugin/job/worker/queue/user/
  project registries or the shared-resource arrays that init creates.
- sim_alloc.c's two sched_make_allocs() stand-ins each ran a full
  xce_sched_core_init(): a whole unused core, plus a re-init of the
  process-wide string-intern and selector tables (two 8 MB tables leaked).
- plugin_unregister() (the plugin registry's datakiller, never run before)
  key_del()'d from the registry being destroyed and skipped fini_fn for
  plugins registered with plugin_register_core().
- The limit plugin's usage-instance table had kill_limit as datakiller for
  xce_vres_t records (bad free on destroy); kill_vres() was an empty stub.
- Remaining (part 2): replay-event payloads are never released after
  xce_core_push_events() (sim_loop.c: documented "accepted leak"), unlike
  driver.c's release_translated_payload(); the adopted core->config is never
  freed (and a CONFIG_PUSH replaces it without freeing the old one);
  kill_sched_job() is shallow; resmgr has no datakiller; snapshot-load data,
  the builtin_fcfs plugin struct and some allocator scratch are not freed.

## Fix
Part 1 (9b61fd99): sched_sim_driver_fini() -- cancel/join the threads the
way sched_fini() does (thread ids now in core.jobpicker/allocator), close
the files, finalize the core; main() calls it after a clean run. Core fini
destroys every registry init makes. The allocator stand-ins set up only
lock, nextid and the aliased resmgr. plugin_unregister() only runs fini_fn.
Usage instances use kill_vres(), which frees the record. Leak at exit on the
reproduction replay: 17,041,405 -> 75,495 bytes.

## Verification
- Test: TODO: name + file; RED before the fix, GREEN after
- Suites: TODO: suite results and build profile
- Live: TODO: soak/deploy run, or n/a and why

## References
- Related: bug-1632, bug-1763 (sim picker/allocator threads never joined)
- run-ha-soak.sh replay gate already runs `--sim` with `ASAN_OPTIONS=detect_leaks=0`