一個proc預編譯代碼時coredump的問題分析

    最近有同事在搞編譯環境遷移，碰上一個問題讓我幫他看一下。
    他建了一個新目錄，而後把如今的代碼拷過去，編譯的時候發現有一個文件編譯不了一執行就出現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不行，則須要梳理出程序運行步驟，猜想在那一步出現問題。簡化或者跳過該步驟看問題是否能重現。若是能夠說明猜想正確，如不行則繼續其它猜想。