最近有同事在搞編譯環境遷移，碰上一個問題讓我幫他看一下，
他建了一個新目錄，然后把現在的代碼拷過去，編譯的時候發現有一個檔案編譯不了一執行就出現core，不知道啥情況，
我進到他的編譯環境，執行make，果然出現了core檔案，
使用file命令分析，發現是proc程式的core，于是使用gdb，想進去看看在哪里core了，
但打開后使用where命令，發現輸出的函式名稱全是問號，根據經驗，這種一般是由于記憶體越界導致函式堆疊資訊被破壞，
于是想試試在gdb里面執行程式，看能不能抓到core現場，
使用make -n，輸出實際編譯的命令，再使用gdb運行porc，設定好運行引數，運行程式，
運行后很快出現sigsegv錯誤，這時使用where命令，發現函式堆疊資訊還在，
但函式名稱很陌生，不是庫函式，又沒原始碼，從函式名稱也判斷不出具體出錯原因，于是斷了使用gdb找原因的想法，
然后我又想，有一些檔案編譯成功，但有一些檔案編譯失敗，會不會是這個.pc檔案里面有什么代碼觸發了proc的bug呢？
于是我把檔案里面的代碼進行刪減，再編譯，
但無論我怎么刪，運行proc預編譯都會coredump，說明應該不是代碼問題，
難道是檔案名字導致的？
于是我把出錯的代碼恢復，并將其改名成另一個可以編譯過的代碼檔案的名稱，再編譯一試，發現可以正常運行，
接著我再找了一個能成功編譯的代碼，使用mv命令把它改名成失敗的代碼名稱，發現預編譯出現core，
經過這兩個試驗，可以確定是檔案名稱導致了proc出現coredump，觀察成功和失敗的代碼檔案名稱，發現長度相差比較大，
會不會是檔案名長度造成的呢？
于是我通過逐步加大檔案名試驗，慢慢定位，終于發現proc在iname引數超過100個字符的時候會出現例外，
因為我這個同事新建的目錄路徑太長，導致路徑名+檔案名超過了100個字符，之前舊編譯環境目錄路徑比較短，所以沒有發現這個問題.
由于沒有保留現場，相應的操作截圖無法展示，這篇文章主要是想介紹一個常用的定位程式問題思路：
1 直接從結果分析，看core檔案，錯誤日志，是否有明確提示問題所在
2 如果1不行，則需要梳理出程式運行步驟，猜測在那一步出現問題，簡化或者跳過該步驟看問題是否能重現，如果可以說明猜測正確，如不行則繼續其它猜測，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/79238.html
標籤：C++
上一篇：c++-zoo動物園