Linux 用戶態進程死循環排查實戰：從 R 狀態 100% CPU 到 GDB 定位業務邏輯缺陷

業務多線程進程 (用戶態) 掛死，OS 反應遲鈍，top 顯示大量線程 R 狀態、CPU 97% us、每線程 ~10% CPU，核心堆疊卡在 retint_careful。本文完整記錄從核心堆疊分析、調度統計、用戶態 GDB 附掛定位死循環的排查鏈路。

現象觀測

• top：85 running threads，Cpu(s): 97.6%us, 2.2%sy，負載 84+。
• 線程名 z_itask_templat，PID 群聚，CPU 均勻分佈 (~10%/thread)。
• cat /proc/PID/task/TID/stack 全卡在 retint_careful+0x14/0x32。

核心堆疊分析

retint_careful 為 x86_64 中斷返回路徑，關鍵邏輯：

bt $TIF_NEED_RESCHED, %edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS
pushq_cfi %rdi
SCHEDULE_USER   # 呼叫 schedule()
popq_cfi %rdi
...
jmp retint_check

堆疊卡在 SCHEDULE_USER 表示：**用戶態進程被中斷打斷，返回時發現需要調度 (TIF_NEED_RESCHED)，進入排程器**。

為何看不到 schedule() 堆疊幀？

汇编直接呼叫 schedule()，未建立標準堆疊幀 (無 push %rbp、mov %rsp,%rbp)，故 perf//proc/stack 看不到。

調度統計確認持續被調度

cat /proc/PID/task/TID/schedstat
# 輸出三欄：sum_exec_runtime, sum_sleep_runtime, nr_switches
# 連續觀測三值持續遞增 → 線程持續獲得 CPU 時間片 → 用戶態非睡眠忙碌

為何每線程僅 10% CPU 而非 100%？

大量同優先級線程 + CFS 調度器 → 時間片均分，無單線程獨佔。

為何未觸發 softlockup？

業務線程優先級普通 (SCHED_OTHER)，不影響最高優先級 watchdog 核心線程調度，故無 softlockup。

為何堆疊總在 retint_careful？

中斷返回是**調度發生的天然點**；我們用 cat /proc/stack 觀測時，觀測進程本身獲得調度，正好在中斷返回路徑 → 必然看到此堆疊。

用戶態定位：GDB 附掛

1. 編譯業務程式加 -g -O0 保留除錯資訊。
2. gdb -p PID 附掛目標進程。
3. info threads 列出所有線程。
4. thread apply all bt 取得所有線程用戶態堆疊。
5. 對比業務邏輯代碼，確認死循環位置 (如 while(1) 無退出條件、鎖未釋放導致自旋等)。

常見用戶態死循環模式

預防與監控建議

• 業務關鍵迴圈加入 sched_yield() 或 usleep() 釋放 CPU。
• 監控 top -H 線程級 CPU，設定告警閾值 (如單線程 > 80% 持續 5 分鐘)。
• 編譯加入 -fno-omit-frame-pointer 保留幀指標，利於 perf/GDB 回溯。
• 生產環境保留 core dump (ulimit -c unlimited、/proc/sys/kernel/core_pattern) 供事後分析。