用C源代碼查找可能出現的問題的工具和方法

編輯感謝大家的意見。我想我的問題有點模糊。因此，我接受了一個明智的答案，並選擇了2個小時的頑固退出（9）調試並找到了，或者至少刪除了兩個錯誤，現在我自豪地解決了一個困難的謎題...... ;-)用C源代碼查找可能出現的問題的工具和方法

I在http://www.spoj.pl上投入了大量時間解決問題的解決方案，該程序在本地處理了我自己創建的所有測試樣本以及問題描述中的樣本。

但是，程序會在服務器上以SIGSEGV中止。在那裏，我上傳了C99 strict語言選項。

編輯：讓我再次清楚地指出，SIGSEGV如何發生絕對沒有暗示。我擁有的唯一信息就是它發生了。感謝@Oli Charlesworth指出這一點。

在本地，我已編制既

gcc -Wall -Wextra -std=c99 -o prog prog.c

和

gcc -Wall -Wextra -m32 -std=c99 -o prog prog.c

，一切工作正常。 64位版本是在普通的Debian擠壓amd64系統上編譯的，-m32版本是在Debian Lenny amd64系統上（但因爲Squeeze與-m32斷開）。

valgrind -v對我的程序也很完美。

我所有的malloc和calloc確保返回值不爲零。除了tsearch，我除了常用的標準功能外沒有其他用途。

我想收集一些關於如何找出問題的指針。（如果有什麼，但假設輸入有意想不到的屬性）

2011-12-12 Jo So

你使用gdb嗎？ – Hgeg

在程序崩潰之前，你能看到程序的輸出嗎？即你可以添加一些'printf（）來查看問題出現在哪裏？ –

@Hgeg：不，當我的系統運行良好時，是否可以將它用於我的優勢？ –

在這樣有限反饋的環境中，一個工具，你可以用的是什麼，我會打電話的問題的根源是「二進制搜索」：

首先上傳將在服務器上運行的最簡單的「hello world」程序，並驗證它不會崩潰。然後，開始添加你的代碼塊，直到程序確實崩潰。當它這樣做時，回溯並添加更小的代碼塊，直到您將其縮小到負責崩潰的特定代碼段。

一旦你把它縮小了，你可以嘗試重新編寫麻煩的代碼塊，或者尋找一種不同的方法來完成正確的結果。

2011-12-12 17:30:37

+1。但我想OP會問「在我的本地環境中我能做些什麼來證明我不依賴於未定義的行爲等？」。 –

@Oli Charlesworth：這聽起來像程序在當地的環境中檢查得很好。在沒有出現問題的系統中搜索不可重現的錯誤將會令人沮喪！ –

當然！但有時候這就是你自己所處的情況。也許你有一個略有不同的GCC版本等等。但是，這個原因幾乎肯定是由於一些無意識的依賴未定義的行爲。 –

用「-g」編譯。

執行命令

ulimit -c

如果返回0，或字節數小的，然後輸入以下內容：

ulimit -c unlimited

這允許無限大小的芯是傾倒。您需要檢查覈心轉儲以查看發生分段故障的位置。在覈心文件上運行gdb以查找此信息。它會將您引向導致核心轉儲的線路，並可能爲您提供有關seg故障原因的更多信息。

請參閱此鏈接的信息，檢查覈心使用gdb轉儲：

的鏈接提供了更多的信息。

2011-12-12 17:45:29

回答