From 833f200268b4aa756a39751ebf99c12148bc8785 Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Tue, 18 Aug 2026 04:49:00 +0000 Subject: [PATCH] chore(wolf): checkpoint buglog.json (959 bugs) --- .wolf/buglog.json | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/.wolf/buglog.json b/.wolf/buglog.json index 16800cad..9e612c93 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -17174,6 +17174,35 @@ ], "occurrences": 1, "last_seen": "2026-08-17T00:00:00Z" + }, + { + "id": "bug-1578", + "timestamp": "2026-08-18T04:45:00Z", + "error_message": "Controller (xce_controller) reproducibly (3/3) exits silently and completely (zero ASAN report, empty stderr, ctrl-1.log ends mid-request with no WARN/ERROR/shutdown line, no core file, cgroup oom_kill=0) within 5-10 seconds after task 6.1's inject_resources() flow (xce_test worker join + resupdate for N resources + quit) completes against a live single-node deployment. Reproduced via the actual run-resource-verify.sh script (2x, default 9-resource set, --keep-running) and via a manual low-level repro feeding cmd_resupdate() the identical xce_test stdin script. Isolated via targeted experiments: a lone controller with zero other interaction stays alive 90s+; controller+scheduler+apiserver deployed with XCE_WORKER_BIN=/bin/true but WITHOUT ever running xce_test survives 100s+; a worker join+quit with NO resupdate at all (no -n/-v pairs) survives 60s+. Only the join+resupdate+quit sequence triggers the crash, isolating it specifically to the resupdate path (very likely cmd_resupdate()'s per-name follow-up xcecli_resval() verification GET-query loop documented in design.md's Test Tooling/C component, or the controller-side opget/resval RPC handling it exercises), not to worker-connect/disconnect lifecycle in general.", + "file": "src/controller/testsuite/test.c (cmd_resupdate's follow-up verification loop) and/or src/controller/opget.c / src/controller/worker.c (the GET/resval RPC path it exercises) -- exact crash site not isolated; no ASAN report was captured in any repro despite an ASAN-instrumented controller build, consistent with an uncatchable termination rather than a caught ASAN abort", + "root_cause": "NOT ROOT-CAUSED -- discovered live during independent adversarial review of resource-value-verification task 6.1 (run-resource-verify.sh's join+inject_resources() addition). The crash is reproducible through task 6.1's own newly-exercised live flow, but the resupdate follow-up verification mechanism it triggers was implemented by an earlier task (2.1/2.2 per design.md's Components table), not task 6.1's Bash-only boundary -- task 6.1 is very likely the first task to exercise this exact code path end-to-end against a full live deployment with a full multi-resource batch, rather than the cause of the underlying defect. Completely silent termination (no ASAN report, no signal-catch message, no log line) despite ASAN instrumentation suggests either an uncatchable external signal (SIGKILL-class) or a crash class ASAN's runtime does not intercept -- needs a debugger/core-dump-based investigation to actually isolate the faulting instruction (ulimit -c was unlimited in the sandbox but no core file was produced by any repro; worth checking core_pattern).", + "fix": "NOT FIXED -- out of boundary for task 6.1's review (run-resource-verify.sh only; the crash is in controller/test.c C code, not the Bash script). Flagging as a CRITICAL, must-address-before-building-further finding: tasks 6.2-6.4 (controller/scheduler/apiserver per-layer verification, per design.md) are wired as direct extension points appended immediately after inject_resources() in run-resource-verify.sh's main() -- if those tasks' controller-side check (Requirement 3's `resval` query) runs more than ~5-10s after injection, it will find the controller already dead, causing spurious FAILs unrelated to whatever those tasks actually implement. Needs a dedicated root-cause task before 6.2 can be built/verified reliably. Workaround for 6.2 in the meantime: query the controller (Requirement 3's `resval` check) IMMEDIATELY after inject_resources() returns, before any scheduler/apiserver bounded-wait polling that could burn the 5-10s window.", + "tags": [ + "controller", + "resupdate", + "cmd_resupdate", + "silent-crash", + "sigkill-class", + "no-asan-report", + "resource-value-verification", + "task-6.1", + "task-6.2-blocker", + "not-root-caused", + "reviewer-discovered", + "CRITICAL" + ], + "related_bugs": [ + "bug-1572", + "bug-1574", + "bug-1577" + ], + "occurrences": 1, + "last_seen": "2026-08-18T04:45:00Z" } ] }