乙個linux的cm出了問題，在開發環境下，是正常的。在現場是崩潰的。
比較環境的區別，輸入的資料不一樣。
還好運氣不錯，拿到現場的資料，在開發環境中也能重現其中乙個資料引起的崩潰問題。
崩潰現象，單步到函式fna, 任務都做了，看任務結果也都有效，但是從函式返回時，還沒到呼叫處，就崩潰了。
這bug現象，我第一感覺就是發生了資料寫的越界，導致棧上的返回位址被覆蓋成了意料之外的位址。
因為其中一條資料可以重現bug, 就去單步，開始沒看出來。再單步時，看看有啥寫資料的操作，用 p 或 x/16ab 列印長度和變數緩衝區，發現這個cm是以前寫的，在記憶體拷貝時，用到了memcpy，但是沒有做引數檢查，當源資料長度超過目標緩衝區長度時，將低位址的變數超長度寫入資料，根據棧上區域性變數的數量和size, 當超長度越界寫入達到一定長度時，就將棧上高位址的函式返回位址寫到了，返回位址亂了。當返回時，到了未知區域，如果執行的彙編**不對了（看運氣），執行了不可訪問的額操作，引起c05錯誤，程式就 崩潰了。
查了一下cm中呼叫memcpy的地方，還很多，就封裝了乙個函式safe_copy_buf，供各處呼叫。重構完成時，必現的崩潰沒有了，偶發的崩潰問題也沒有了。
看來，要使程式健壯，每個細節都要注意 :)
當**片段使用超過2次，都值得封裝乙個函式，供其他函式呼叫。
這樣做，維護性，可除錯性，**清晰度, 都提高了。
當工程**量上來時，如果出了這種越界寫的問題，又不能必現（偶發），還是蠻頭疼的。
void safe_copy_buf(unsigned
char* puc_dst, int i_len_dst, unsigned
char* puc_src, int i_len_src)
i_len_to_copy = (i_len_src < i_len_dst) ? i_len_src : i_len_dst;
memset(puc_dst, 0, i_len_dst);
if (i_len_to_copy <= 0)
memcpy(puc_dst, puc_src, i_len_to_copy);
} while (0);
}
Memcpy越界操作導致free崩潰分析
1 include stdafx.h 2 include 3 include 4 include56 int tmain int argc,tchar argv 7 首先為什麼第11行沒有崩潰呢，其實這個跟第16行是一樣的，這個我們在操作這塊記憶體的時候，該塊記憶體不是系統暫用的記憶體區域，它就是一...
C 呼叫C 介面導致記憶體越界 引起程式崩潰
問題描述 介面呼叫後，功能正常，但是軟體操作若干次後 單擊介面 影象操作 影象瀏覽等任意操作 軟體直接崩潰到c 程式入口處，錯誤提示中錯誤 0x00000005,明顯是記憶體訪問越界等典型問題 分析解決問題 但是檢查 並確認無記憶體洩漏 注意 不是記憶體洩漏的問題造成的，卻朝著記憶體洩漏的方向走下去...
指標引起的崩潰分析
指標引起的崩潰問題，常見的原因如下 勞資還沒乾貨呢，你就讓勞資幹活了。這種情況實際專案當中是非常多的，即使你用了智慧型指標，也還是無法避免。當工程很龐大複雜而且乙個類都有可能多個人負責的時候，那麼這個指標的訪問堆疊確實千變萬化，你無法確定是 調到這裡來的，也就無法確保該指標一定指向了某一物件，當然判...