lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(lib): zarray_fini/xlist_fini must reset caps/count, not just free data

Browse source 
A user-reported core dump showed xce_scheduler crashing with SIGSEGV in
its allocator thread: zarray_get_ex dereferencing a NULL array->data
inside match_job_host_limit_() (plugins/limit.c), reached via schedobj.c's
reset_sched_obj().

Root cause: zarray_fini() freed array->data and set it to NULL, but left
array->caps/count/pos at their stale pre-fini values instead of resetting
to the safe (0,0,0) state zarray_init() establishes. xlist_fini() had the
identical gap. Both structs' own bounds checks (`idx >= caps`) treat a
nonzero caps as a guarantee that data is a valid allocation -- a
guarantee broken for any caller that reuses the same struct after
_fini() without re-init.

schedobj.c's reset_sched_obj() does exactly that: it tears down a job's
own PERSISTENT schedobj (reused for the job's whole lifetime, not a
disposable scratch object) whenever the cluster's config version has
advanced, with no matching re-init. Once a host-limit match had grown
hlimits' capacity, and the config version bumped again while that job
sat PEND, the next allocation attempt for the same job dereferenced the
torn array -- exactly matching the reported backtrace. This same crash
class had already caused at least one earlier, never-successfully-root-
caused crash near the same call site (2026-08-17).

Fixed at the library-primitive level rather than reset_sched_obj()'s
call site: zarray_fini()/xlist_fini() now reset caps/count/pos to 0,
matching what _init() establishes. This makes every existing
_fini()-then-reuse caller correct by construction, with zero changes
needed at any call site. Audited every non-test zarray_fini()/
xlist_fini() call site first -- none relies on caps/count surviving
_fini(), so this is a pure safety improvement, not a behavior change.

RED confirmed by temporarily disabling both resets: new tests failed
cleanly ("Expected 0 Was 4" / "Expected 0 Was 2", the stale pre-fini
caps). GREEN confirmed restored: full lib suite 314/314, scheduler
suite 77/77, zero regressions.

bug-1817.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC
This commit is contained in:
Rongsong Shen 2026-09-16 02:31:53 +00:00
parent 7f3237aee1
commit 63de947305
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
4 changed files with 137 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

14
src/lib/xlist.c
View file

@ -158,6 +158,17 @@ void* xlist_find(xlist_t* l, xlist_find_fn_t fn, ...)
return it;
}
/*
* xlist_fini - tears down `l`'s backing storage, leaving it in the SAME
* safe, empty state xlist_init() establishes (data=NULL, caps=0, count=0)
* -- NOT just data=NULL with caps/count still holding their pre-fini
* values. See zarray_fini()'s own doc comment (zarray.c) for the exact
* live crash this class of bug caused (schedobj.c's reset_sched_obj(),
* the analogous xlist_t field obj->glimits) -- xlist_get()'s bounds check
* has the identical shape (`idx >= l->caps`), so a stale-nonzero caps with
* data==NULL is just as exploitable here. No existing caller relies on
* caps/count surviving an xlist_fini() call.
*/
void xlist_fini(xlist_t* l)
{
if (l == NULL) {
@ -165,5 +176,6 @@ void xlist_fini(xlist_t* l)
}
FREEUP(l->data);
return;
l->count = 0;
l->caps = 0;
}