指標引起的崩潰問題，常見的原因如下：
勞資還沒乾貨呢，你就讓勞資幹活了。
這種情況實際專案當中是非常多的，即使你用了智慧型指標，也還是無法避免。當工程很龐大複雜而且乙個類都有可能多個人負責的時候，那麼這個指標的訪問堆疊確實千變萬化，你無法確定是**調到這裡來的，也就無法確保該指標一定指向了某一物件，當然判空不一定能解決這類問題的邏輯錯誤，但是至少能保證不會在這裡崩潰。
野孩子還到處亂跑，不出問題才怪。
野指標的原因有簡單的也有複雜的，單執行緒內這個問題其實很好解決，怕的就是多執行緒，多處都存在釋放這個物件的可能，偶現了崩潰直接看**根本無法確定是**多管閒事釋放了該物件，而此時的dump檔案也無能為力，因為dump也無法告訴你這個物件到底是在**釋放了，只能告訴你在這裡指標野了，崩潰了。遇到這類偶現問題，乙個好的方案是可以打出乙個測試版本，在所有釋放該物件的地方強制崩潰，這樣就有可能捕獲到是哪個小婊砸在意料之外釋放了。僅供參考的乙個小技巧。
當然這種說法是欠準確的，你乙個類的虛表被破壞了那可真是奇了個葩，更多可能是虛指標亂了，有可能你「任性」的做了型別轉換，導致這個指標根本不應該訪問那個類的虛函式，但是強制型別轉換用的又是如此的順手，只能祈禱你自己編碼更加規範，思路更加嚴謹了。另乙個原因，就是其他地方越界了，非法寫入導致這個指標內容被破壞了，這時候不崩潰才怪呢。
由memcpy越界引起的崩潰
乙個linux的cm出了問題，在開發環境下，是正常的。在現場是崩潰的。比較環境的區別，輸入的資料不一樣。還好運氣不錯，拿到現場的資料，在開發環境中也能重現其中乙個資料引起的崩潰問題。崩潰現象，單步到函式fna,任務都做了，看任務結果也都有效，但是從函式返回時，還沒到呼叫處，就崩潰了。這bug現象，我...
利用「崩潰軌跡」分析崩潰
原文出自 聽雲技術部落格 崩潰，嚴重傷害使用者的情感，嚴重損害使用者體驗，罪惡行徑簡直令人髮指，特請xx獅 xx猿火速緝拿案犯歸案，刻不容緩，欽此。上圖所示，已經定位到某原始檔的某行，再加上崩潰message，崩潰的原因就顯而易見了。但有些崩潰的原因就不是那麼顯而易見了，往往需要尋找更多蛛絲馬跡來定...
利用「崩潰軌跡」分析崩潰
更多技術乾貨請戳 聽雲部落格 崩潰，嚴重傷害使用者的情感，嚴重損害使用者體驗，罪惡行徑簡直令人髮指，特請xx獅 xx猿火速緝拿案犯歸案，刻不容緩，欽此。上圖所示，已經定位到某原始檔的某行，再加上崩潰message，崩潰的原因就顯而易見了。但有些崩潰的原因就不是那麼顯而易見了，往往需要尋找更多蛛絲馬跡...