From 6247bf052b840f2b6641e93f1eb302bdf8d3faee Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Fri, 25 Sep 2026 13:27:08 +0000 Subject: [PATCH] chore(buglog): bug-1766 fixed (601b245e) Co-Authored-By: Claude Opus 5.5 (1M context) --- .wolf/buglog.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.wolf/buglog.json b/.wolf/buglog.json index 428bfb10..cd1174fe 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -25183,9 +25183,9 @@ }, { "id": "bug-1766", - "status": "open", - "status_updated": "2026-09-24", - "status_note": "compound allocation keeps partial alloc on later primary failure, no rollback (scheduler.c)", + "status": "fixed", + "status_updated": "2026-09-25", + "status_note": "601b245e", "timestamp": "2026-09-04T08:03:28Z", "error_message": "OPEN, NOT A CRASH -- discovered while reviewing the scheduler-allocation spec requirements against live scheduler.c source: sched_make_compound_allocation() does not roll back already-succeeded primaries when a LATER primary in the same COMPOUND resreq fails allocation, and its own post-loop code can misattribute a partial allocation to a failed compound.", "root_cause": "sched_make_compound_allocation() (src/scheduler/src/scheduler.c:206-238) loops over a COMPOUND resreq's primaries, calling sched_make_primary_alloc_(sched, &ctx) for each with ONE shared ctx across the whole loop. On a mid-loop failure (rc <= 0) it just `break`s -- it never undoes the primaries that already succeeded (no zeroing of ctx.alloc, no reversal of any resource state those primaries touched). Worse: seqjob/parjob's job_alloc_fn sets ctx->alloc directly on success (see seqjob_allocator.c my_alloc()), so if primary 1 of a 2-primary compound succeeds (leaving ctx.alloc non-NULL) and primary 2 then fails, the function's unconditional post-loop `if (ctx.alloc != NULL) { MOVE_PTR(obj->alloc, ctx.alloc); }` still fires regardless of the overall `rc <= 0` -- so a COMPOUND job that is reported as allocation-FAILED can still end up with obj->alloc set to primary 1's partial, orphaned allocation. requirements.md for scheduler-allocation (Req 9 AC2) had assumed, based on the sibling scheduler-framework brief's own text, that this path already 'tracks allocations in ctx and cleans up on failure' -- that claim does not hold against the actual code; requirements.md was corrected during this review. Not yet confirmed whether the orphaned ctx.alloc is ever read for a job later found to be PEND/failed (i.e. whether this is dormant/leak-only or produces an observably wrong result) -- not investigated further since it is out of the scheduler-allocation spec's own boundary (Req 9 AC2 explicitly freezes COMPOUND/ALTER dispatch as unchanged).",