這篇解決一個(gè)現(xiàn)場(chǎng)最頭疼的問題設(shè)備運(yùn)行中進(jìn)程突然消失沒有報(bào)警、沒有日志、沒有提示操作員只看到畫面沒了。怎么提前兜底、怎么事后定位、怎么從代碼里識(shí)別壞味道筆者因?yàn)檫@個(gè)問題吃了不少苦頭一開始對(duì)于軟件跑著跑著就不見了這問題也是慌得不行現(xiàn)在想想還是經(jīng)驗(yàn)不足所以記錄一下自己的一些應(yīng)對(duì)方法一、先認(rèn)清閃退和報(bào)警停機(jī)的區(qū)別設(shè)備軟件出問題有兩種形態(tài)排查方法完全不同。報(bào)警停機(jī)軟件還在跑彈了個(gè)窗或停在某步日志里有記錄。這是「可控故障」比如軸超時(shí)、真空失敗。你到現(xiàn)場(chǎng)看日志、看報(bào)警碼就能定位。閃退進(jìn)程直接沒了Windows 任務(wù)管理器里找不到這個(gè)進(jìn)程。日志可能只寫到一半操作員只記得「突然畫面沒了」。這是「不可控崩潰」也是最讓人崩潰的——因?yàn)楝F(xiàn)場(chǎng)什么都沒留下。設(shè)備軟件里閃退的根因歸納起來就那么幾類。不是玄學(xué)是有規(guī)律可循的。先說原因再說怎么兜底最后說怎么查。二、閃退的五大根因干了幾年設(shè)備軟件你會(huì)發(fā)現(xiàn)閃退翻來覆去就是這五種。根因一數(shù)組越界// 8 個(gè)吸嘴訪問第 10 個(gè)vectorvectorPicker* m_vvPickers; // size 8Picker* p m_vvPickers[10][3]; // 越界直接崩設(shè)備軟件里越界高發(fā)場(chǎng)景吸嘴陣列按Pos{row, col}訪問row或col算錯(cuò)了。Buffer 層數(shù)循環(huán)for (j 0; j N; j)N 寫錯(cuò)了。配置文件讀出來一個(gè)意外的索引值直接拿來訪問數(shù)組。越界不一定立刻崩。讀到的內(nèi)存可能恰好可讀程序繼續(xù)跑但數(shù)據(jù)是錯(cuò)的也可能恰好不可讀CPU 觸發(fā)訪問違例進(jìn)程直接死。這就是為什么越界類 bug 時(shí)有時(shí)無、難以復(fù)現(xiàn)。根因二空指針解引用// 手臂還沒創(chuàng)建就調(diào)Arm* m_pArm nullptr;m_pArm-PickStation(); // 解引用空指針崩設(shè)備軟件里空指針高發(fā)場(chǎng)景初始化順序錯(cuò)了用的時(shí)候?qū)ο筮€沒 new。某個(gè)分支里忘了賦值另一個(gè)分支直接用。指針存在但對(duì)象已經(jīng)被 delete變成野指針?？罩羔樈庖迷?Windows 上通常觸發(fā)0xC0000005訪問違例dmp 里一眼能看到。根因三野指針delete 了還在用// 對(duì)象銷毀了指針還在Arm* p new Arm();delete p;p-PickStation(); // p 指向的內(nèi)存已釋放行為未定義野指針比空指針更難查因?yàn)閜不是nullptr判空檢查過不了。程序可能崩、可能跑出亂七八糟的數(shù)據(jù)、可能恰好沒事——取決于那塊內(nèi)存被誰重新分配了。設(shè)備軟件里野指針高發(fā)場(chǎng)景手動(dòng)delete后忘了置空。多線程里一個(gè)線程 delete另一個(gè)線程還在用。容器clear后還持有容器里元素的指針。根因四多線程同時(shí)讀寫共享數(shù)據(jù)// 線程 A 正在 push_backm_pickers.push_back(new Picker());// 線程 B 同時(shí)在遍歷for (auto* p : m_pickers) { p-Check(); } // 迭代器失效崩這是設(shè)備軟件里最隱蔽的閃退原因。std::vector在push_back時(shí)如果發(fā)生擴(kuò)容內(nèi)部?jī)?nèi)存地址全變了另一個(gè)線程正拿著舊迭代器遍歷直接訪問已釋放內(nèi)存。表現(xiàn)通常是偶發(fā)崩潰多線程高負(fù)載時(shí)才出現(xiàn)單線程調(diào)試時(shí)怎么都復(fù)現(xiàn)不了。根因五析構(gòu)順序錯(cuò)誤// 單例持有業(yè)務(wù)對(duì)象class Logger : public SingletonLogger{vectorActor* m_actors; // 程序退出時(shí) Actor 先析構(gòu)Logger 后析構(gòu)};// Logger 析構(gòu)時(shí)訪問 m_actors 里的元素但 Actor 已經(jīng)沒了Logger::~Logger() { for (auto* a : m_actors) a-GetName(); } // 崩程序退出時(shí)的閃退大多是析構(gòu)順序問題。單例、全局對(duì)象、static 成員的析構(gòu)順序由 C 運(yùn)行時(shí)決定不保證和你的依賴順序一致。三、第一道防線dmp 兜底平時(shí)就配好閃退最怕的是「沒有現(xiàn)場(chǎng)」。dmp 文件就是崩潰瞬間的「現(xiàn)場(chǎng)照片」能看到崩潰在哪一行、調(diào)用棧是什么、局部變量值是多少。dmp 兜底不是出事后補(bǔ)的是平時(shí)開發(fā)時(shí)就配好的。 等設(shè)備在現(xiàn)場(chǎng)掛了你才發(fā)現(xiàn)沒配 dmp那就只能靠猜了。方案一Google Breakpad / CrashpadGoogle 出的開源崩潰捕獲庫(kù)跨平臺(tái)工業(yè)級(jí)穩(wěn)定。原理在程序啟動(dòng)時(shí)注冊(cè)一個(gè)異常處理器崩潰時(shí)把進(jìn)程內(nèi)存、寄存器、線程棧寫成一個(gè) dmp 文件。程序退出前還能附帶把 dmp 上報(bào)到指定目錄或服務(wù)器。// Breakpad 集成示意#include client/windows/handler/exception_handler.hbool OnMinidump(const wchar_t* dump_path, const wchar_t* id, void* ctx, EXCEPTION_POINTERS* exinfo, MDRawAssertionInfo* assertion, bool succeeded){// 把 dmp 復(fù)制到固定目錄帶版本號(hào)CopyDumpToArchive(dump_path, GetCurrentVersion());return succeeded;}int main(){google_breakpad::ExceptionHandler eh(LD:\\dumps, // dmp 存放目錄nullptr,OnMinidump,nullptr,google_breakpad::ExceptionHandler::HANDLER_ALL);// ... 程序正常運(yùn)行}方案二Windows 原生 SetUnhandledExceptionFilter不想引入第三方庫(kù)時(shí)用 Windows API 自己捕獲未處理異常調(diào)MiniDumpWriteDump生成 dmp。#include dbghelp.hLONG WINAPI MyCrashHandler(EXCEPTION_POINTERS* ep){HANDLE hFile CreateFile(LD:\\dumps\\crash.dmp,GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, 0, nullptr);MINIDUMP_EXCEPTION_INFO info;info.ThreadId GetCurrentThreadId();info.ExceptionPointers ep;info.ClientPointers FALSE;MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(),hFile, MiniDumpNormal, info, nullptr, nullptr);CloseHandle(hFile);return EXCEPTION_EXECUTE_HANDLER;}int main(){SetUnhandledExceptionFilter(MyCrashHandler);// ... 程序正常運(yùn)行}dmp 配好了怎么用用 Visual Studio 打開 dmp 文件或 WinDbg。確保有對(duì)應(yīng)版本的 PDB 符號(hào)文件。自動(dòng)跳到崩潰行看調(diào)用棧、看局部變量。定位到「哪個(gè)函數(shù)第幾行崩了、怎么走到這的」。關(guān)鍵要求每個(gè)發(fā)布版本都要保留對(duì)應(yīng)的 PDB否則 dmp 打開只有地址沒有函數(shù)名。PDB 和 exe/dll 必須版本完全對(duì)應(yīng)。dmp 能告訴你「崩在哪」但有時(shí)候你還需要知道「怎么走到那的」。日志就是崩潰前的足跡。閃退場(chǎng)景下日志的特殊要求普通日志寫「動(dòng)作完成」就夠了但閃退時(shí)程序可能崩在「動(dòng)作中間」最后一條日志是上一步的。所以關(guān)鍵動(dòng)作要寫「開始」和「完成」兩條RunRetArmErr DoPick(){Log( 開始取料 站: st-name); // 開始日志auto ret MoveTo(pickPos);// 如果這里崩了至少知道是取料過程中崩的Log( 取料完成 結(jié)果: ret.GetSerialErrorString()); // 完成日志return ret;}和前綴讓日志一眼看出「這個(gè)動(dòng)作開始了但沒完成」就是崩在中間。狀態(tài)快照日志周期性 dump 當(dāng)前狀態(tài)崩潰時(shí)能看到崩潰前的整體狀態(tài)void Arm::DumpState(){Log(狀態(tài)快照 step ToString(m_step.Get()) station (m_curStation ? m_curStation-name : null) pickerCount to_string(m_pickers.size()));}每隔幾秒或每個(gè)步驟切換時(shí)調(diào)一次。崩潰后看最后一條快照就知道狀態(tài)機(jī)走到哪了。四、第二道防線日志寫全閃退前留下最后足跡dmp 能告訴你「崩在哪」但有時(shí)候你還需要知道「怎么走到那的」。日志就是崩潰前的足跡。閃退場(chǎng)景下日志的特殊要求普通日志寫「動(dòng)作完成」就夠了但閃退時(shí)程序可能崩在「動(dòng)作中間」最后一條日志是上一步的。所以關(guān)鍵動(dòng)作要寫「開始」和「完成」兩條RunRetArmErr DoPick(){Log( 開始取料 站: st-name); // 開始日志auto ret MoveTo(pickPos);// 如果這里崩了至少知道是取料過程中崩的Log( 取料完成 結(jié)果: ret.GetSerialErrorString()); // 完成日志return ret;}和前綴讓日志一眼看出「這個(gè)動(dòng)作開始了但沒完成」就是崩在中間。狀態(tài)快照日志周期性 dump 當(dāng)前狀態(tài)崩潰時(shí)能看到崩潰前的整體狀態(tài)void Arm::DumpState(){Log(狀態(tài)快照 step ToString(m_step.Get()) station (m_curStation ? m_curStation-name : null) pickerCount to_string(m_pickers.size()));}每隔幾秒或每個(gè)步驟切換時(shí)調(diào)一次。崩潰后看最后一條快照就知道狀態(tài)機(jī)走到哪了。五、第三道防線沒有 dmp 時(shí)差異化排查最痛苦的情況dmp 沒配或沒生成日志也不全只有操作員一句「突然沒了」。這時(shí)候靠差異化排查。第一步找到最近穩(wěn)定的版本問幾個(gè)問題上周能跑嗎上個(gè)月呢哪個(gè)版本開始出現(xiàn)閃退的那段時(shí)間改了什么版本管理好的話git log看提交歷史找到穩(wěn)定版本和出問題版本之間的差異。第二步對(duì)比差異代碼# 看兩個(gè)版本之間的差異git diff v1.2.0 v1.3.0 -- src/重點(diǎn)看新加的數(shù)組訪問有沒有邊界檢查。新加的指針有沒有判空。新加的多線程邏輯有沒有加鎖。新加的 delete 有沒有配對(duì)。第三步讀代碼識(shí)別壞味道不需要運(yùn)行純靠眼睛掃。設(shè)備軟件閃退的壞味道就那么幾種壞味道一數(shù)組訪問沒有邊界保護(hù)// 壞味道Picker* p m_vvPickers[pos.row][pos.col];// pos 從哪來有沒有可能越界// 好習(xí)慣if (pos.row 0 || pos.row (int)m_vvPickers.size()) { Alarm(越界); return; }if (pos.col 0 || pos.col (int)m_vvPickers[0].size()) { Alarm(越界); return; }Picker* p m_vvPickers[pos.row][pos.col];壞味道二裸指針不判空// 壞味道m(xù)_pArm-PickStation(); // m_pArm 可能是 nullptr// 好習(xí)慣if (!m_pArm) { Alarm(手臂未初始化); return; }m_pArm-PickStation();壞味道三多線程共享容器裸操作// 壞味道// 線程 Am_events.push_back(ev);// 線程 Bfor (auto e : m_events) { ... } // 沒有鎖可能崩// 好習(xí)慣// 線程 A{lock_guardmutex lk(m_mtx);m_events.push_back(ev);}// 線程 B{lock_guardmutex lk(m_mtx);for (auto e : m_events) { ... }}壞味道四delete 后不置空// 壞味道delete m_pBuffer;// 后面某處又用了 m_pBuffer// 好習(xí)慣delete m_pBuffer;m_pBuffer nullptr;壞味道五static/全局對(duì)象持有業(yè)務(wù)指針// 壞味道class Logger : public SingletonLogger{Actor* m_pArm; // 程序退出時(shí) Actor 先析構(gòu)Logger 后析構(gòu)訪問就崩};// 好習(xí)慣單例不持有業(yè)務(wù)對(duì)象或用 weak_ptrclass Logger : public SingletonLogger{weak_ptrActor m_pArm; // 析構(gòu)后 weak_ptr 自動(dòng)失效};第四步逐步回退如果差異代碼太多看不過來用「二分法」回退把最近一半改動(dòng)注釋掉看還崩不崩。不崩了 → 問題在注釋掉的那一半里。還崩 → 問題在沒注釋的那一半里。繼續(xù)二分直到定位到具體改動(dòng)。六、防閃退的編碼習(xí)慣清單把前面所有原因?qū)?yīng)的防御寫法整理成清單平時(shí)編碼對(duì)照?qǐng)?zhí)行。閃退原因防御寫法一句話數(shù)組越界訪問前查size()用at()代替[]永遠(yuǎn)不信任索引值空指針指針用前判nullptr判空比崩潰便宜野指針用shared_ptr代替裸new/delete讓生命周期可管多線程讀寫共享容器加鎖或用并發(fā)隊(duì)列vector 不是線程安全的析構(gòu)順序單例不持有業(yè)務(wù)對(duì)象或用weak_ptr退出時(shí)順序不可控配置異常值從 ini/json 讀的索引先校驗(yàn)范圍配置可能被人改錯(cuò)容器遍歷中修改遍歷時(shí)不要 push/erase迭代器會(huì)失效七、一個(gè)真實(shí)的排查故事把前面的方法串起來看一個(gè)真實(shí)場(chǎng)景怎么查?，F(xiàn)象設(shè)備運(yùn)行 2 小時(shí)后偶發(fā)閃退無規(guī)律dmp 有生成。第一步查 dmp用 VS 打開 dmp調(diào)用棧Picker::CheckVacuum()Arm::PickStation()TargetTransport::TransportFlow()Arm::WorkFlow()崩在Picker::CheckVacuum里訪問了一個(gè)空指針。第二步看局部變量dmp 里this指針是0x00000000說明Picker*是空指針。誰傳進(jìn)來的往上看調(diào)用棧Arm::PickStation里Picker* p m_vvPickers[pos.row][pos.col];p-CheckVacuum(); // p 是空的第三步看日志最后一條日志14:23:05 開始取料 站:Buffer1 位置(7,3)沒有「取料完成」日志說明崩在取料過程中。pos.row7但m_vvPickers只有 8 行0-7row7沒越界。再看col3m_vvPickers[7]只有 3 個(gè)元素0-2col3越界了取到一個(gè)空位置。第四步定位根因pos.col3從哪來的查CalFlag計(jì)算邏輯發(fā)現(xiàn)某個(gè)邊界條件下col算成了size而不是size-1。第五步修復(fù) 加防御// 修復(fù)計(jì)算邏輯if (col 0) col--;// 加防御if (pos.col (int)m_vvPickers[pos.row].size()){Alarm(吸嘴位置越界);return;}這就是完整鏈路dmp 定位崩在哪 → 日志還原怎么走到那 → 代碼審查找到根因 → 修復(fù) 加防御。八、可復(fù)用結(jié)論閃退五大根因數(shù)組越界、空指針、野指針、多線程讀寫、析構(gòu)順序。翻來覆去就這五種。dmp 是第一道防線平時(shí)就配好用 Breakpad 或SetUnhandledExceptionFilter每個(gè)版本留 PDB。日志是第二道防線關(guān)鍵動(dòng)作寫「開始」和「完成」兩條崩在中間能看出來。沒有 dmp 時(shí)靠差異化排查找穩(wěn)定版本 → 對(duì)比差異 → 讀代碼識(shí)別壞味道 → 二分回退定位。防御編碼習(xí)慣數(shù)組查邊界、指針判空、用shared_ptr、共享容器加鎖、單例不持業(yè)務(wù)對(duì)象。排查鏈路dmp 定位崩在哪 → 日志還原怎么走到那 → 代碼審查找根因 → 修復(fù) 加防御。設(shè)備軟件的閃退不是「運(yùn)氣不好」是「防御沒做到位」。dmp 兜底平時(shí)配好日志寫全編碼習(xí)慣到位大部分閃退都能在第一時(shí)間定位。等到現(xiàn)場(chǎng)掛了才發(fā)現(xiàn)什么都沒留那才是真正的災(zāi)難。