無窮迴圈、邏輯失控 Infinite loop / runaway logic

原因 ID sp-infinite-loop · 主要負責 遊戲開發團隊（伺服器開發）

因 bug 導致一個 tick 結束不了時，伺服器就會停住，看門狗會強制重新啟動。

為什麼 條件寫錯導致迴圈結束不了，或遞迴失控 → 於是 tick 結束不了，伺服器停止 → 畫面上 定格後所有人斷線

症狀: 定格, 斷線
因素: 停滯
誰會遇到: 特定地點／頻道, 整個伺服器
何時: 做特定動作時, 偶爾隨機發生
負責單位: 主要負責 遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 設定迴圈次數上限、看門狗、撰寫重現問題輸入的測試。
圖表上: 連線同時大量中斷 · 連線數、各執行緒的 CPU
查看位置: 停住期間用 pidstat -t 1 看各執行緒的 CPU，並用 perf top -t（執行緒 ID）或 gdb 確認以 100% 在跑的執行緒卡在哪個函式。已經重新啟動時，看看門狗逾時紀錄（systemd 的 WatchdogSec、Kubernetes liveness probe 失敗）
符合的跡象: 伺服器停住期間，一個遊戲執行緒 CPU 貼在 100%，堆疊一直在同一個函式或迴圈內打轉
不符合的跡象: 停住期間 CPU 接近 0 時，是死結或在等外部回應
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

systemd.service(5) — Linux manual page systemd
WatchdogSec=：服務沒有在設定時間內送出存活訊號（WATCHDOG=1）時視為失敗並終止，再依 Restart= 設定自動重新啟動
Liveness, Readiness, and Startup Probes Kubernetes
以 liveness probe 偵測「仍在執行卻無法前進」的狀態並重新啟動；預設每 10 秒檢查一次，連續失敗 3 次就重新啟動
pidstat(1) — Linux manual page sysstat
加 -t 可一併顯示處理程序所屬各執行緒的統計（CPU 使用率等）
perf-top(1) — Linux manual page perf
依函式（symbol）即時顯示執行中執行緒（-t）或處理程序（-p）的 CPU 使用占比