chore(wolf): checkpoint buglog.json (1055 bugs)

.wolf/buglog.json

@@ -19486,6 +19486,32 @@
       ],
       "occurrences": 1,
       "last_seen": "2026-08-26T17:15:00Z"
+    },
+    {
+      "id": "bug-1714",
+      "timestamp": "2026-08-26T18:35:00Z",
+      "error_message": "User-reported live deployment: xce_scheduler process died and restarted unexpectedly (PID changed from 3964918 to 4137745 in scheduler.log with a ~79s gap, no manual restart by the user) during a live 3-node cluster test session; xceadmin briefly reported 'Error: scheduler disconnected' (the already-correct bug-1693 disconnect-detection path in cluster.c, working as designed -- not itself a bug) then recovered on the next attempt once the scheduler rejoined. User confirmed via `sudo dmesg -T` a REAL kernel-level segfault: `xce_scheduler[2815660]: segfault at 30 ip 0000601569e1fb35 sp 00007db7db1f6e00 error 4 in xce_scheduler[23b35,601569e01000+de000] likely on CPU 5 (core 16, socket 0)` -- though this specific dmesg entry is dated Aug 25 19:21:39, a DIFFERENT, earlier occurrence than today's specific restart (Aug 26 ~18:00-18:02), not necessarily the direct cause of THIS restart. No core dump exists for xce_scheduler anywhere in /var/lib/systemd/coredump/ (only xce_controller and python entries present, despite the scheduler segfault being kernel-confirmed) -- a separate, notable gap in this environment's crash-capture coverage for the scheduler process specifically.",
+      "file": "src/scheduler/ (exact crash site unknown -- no core dump, no backtrace available for either occurrence)",
+      "root_cause": "NOT ROOT-CAUSED -- confirmed real (kernel dmesg segfault line, error code 4 = user-mode read fault, not a random/unrelated event) but no core dump or backtrace exists for any xce_scheduler crash observed so far, including the Aug 25 19:21:39 kernel-confirmed occurrence and today's (Aug 26, ~18:00-18:02) restart (PID 3964918 -> 4137745), which may or may not be the SAME underlying bug -- the two occurrences have not been correlated beyond both being unexplained scheduler deaths. Notable secondary finding: systemd-coredump is confirmed working for xce_controller (4 real core.xce_controller.*.zst files captured and used earlier this session, see bug-1699) but has captured ZERO xce_scheduler crashes despite at least one kernel-confirmed scheduler segfault -- needs investigation on the user's real machine (check core_pattern/ulimit -c/systemd-coredump size or process-name filtering specifically for the scheduler binary; also worth checking whether the scheduler's own launch wrapper -- start-scheduler.sh, a bare unwrapped invocation with no core-dump-enabling ulimit call -- inherits a different ulimit -c than however the controller happens to get its unlimited setting).",
+      "fix": "NOT ATTEMPTED -- cannot fix an uninvestigated crash responsibly. Next steps if revisited: (a) fix the core-dump capture gap first (confirm ulimit -c/core_pattern actually applies to xce_scheduler processes the same way it does to xce_controller, on the user's real machine -- this blocks ALL future scheduler crash forensics, not just this one); (b) once captured, decode the NEXT scheduler core the same way bug-1699's controller cores were analyzed (systemd-coredump or manual zstd -d + gdb against the matching build.dbg/scheduler/xce_scheduler binary); (c) correlate against scheduler.log's own last lines before each death for behavioral context (what was the scheduler doing in the moment it died -- dispatch round, resource accounting, a specific request type).",
+      "tags": [
+        "scheduler",
+        "segfault",
+        "sigsegv",
+        "unreproduced",
+        "no-core-dump",
+        "coredump-capture-gap",
+        "found-live",
+        "needs-live-repro",
+        "needs-owner",
+        "unfixed",
+        "kernel-confirmed"
+      ],
+      "related_bugs": [
+        "bug-1699"
+      ],
+      "occurrences": 2,
+      "last_seen": "2026-08-26T18:35:00Z"
     }
   ]
 }