詭異難解決的錯誤：Windows已在xxx.exe中觸發一個斷點

windows已在xxx.exe中觸發一個斷點,其原因可能是堆被損壞,這說明xx.exe中或它所載入的任何DLL中有bug。 原因也可能是使用者在xx.exe具有焦點時按下了F12。輸出視窗可能提供了更多診斷資訊 。

    當碰到此種錯誤的時候，基本上是因為我們在編寫程式的時候，在處理數組或者指標的時候出現了越界（最可能）或者超長

的情況，從而導致了對棧堆的損壞。

    我自己的程式就是因為一個很隱藏的變數沒有置零造成的，在每次重用cor空間時，correlation記得置為0了，而cor_index卻沒有set 為 0.

因而隨著多次重用，cor_index的值越來越大，從而在訪問cor[cor_index]時出現嚴重越界.作這些設定，都跟add_correlation方法的實現有關，

裡面如何使用correlation以及cor_index直接導致了在重複調用這個函數時必須重設cor[].correlation=0，cor_index=0. 

     當然造成這個錯誤很難尋找的原因，編程習慣有點關係。在設計演算法時，沒有更多的考慮複用的簡單性，過多的設定了一些全域變數，同時設計的

演算法也不具一般性。這些以後都要注意改進。這個問題困擾了整整兩天，一開始是在linux系統下編程實現的，由於linux下的調試環境不是特別熟悉，

也不是很直觀，我調試了一天都沒發現問題所在，只要在釋放記憶體空間的地方，注釋掉這些記憶體釋放語句，程式就還能運行一下，但是我始終覺得這些

地方的記憶體釋放是絕對沒問題，但是為什麼加上這些語句之後反而運行不了幾步呢？我困惑了，我開始懷疑自己對記憶體管理的知識了。因此我將所有的

會讓程式報錯的記憶體釋放語句都注釋了。這時，當資料量不大的時候，程式正確執行；但是當資料量再大點的時候，就直接卡死了或者是說某地方越界

了。這種結果讓我開始懷疑gsl_matrix庫是不是有問題，因此我就將gsl_matrix全部用自己得矩陣庫替換，還是發現有錯誤。

    因此我確定了，是程式的其他地方出問題了。為了快速找出錯誤，我又重新改寫了程式，將程式搬到了windows平台上，通過調試發現了這個錯誤。

再靜過心，查看的時候，發現是cor_index的重設問題。

    對一個程式員來說，不可以說自己的程式完全沒有錯誤，很多時候一些錯誤都是你沒發現而已，一般的情況這些錯誤並不表現出來，當它表現出來的

時候，也許已經是致命的錯誤了。對自己已有東西掌握我們也應該去懷疑，因為我們不一定完全理解正確了，也許有我們沒有考慮到的。在使用別人的庫

的時候，如果有問題，我們也許也更多地去考慮自己的問題。總之，編程需要耐心，需要不斷地去實踐，需要我們不停地去學習。