除錯linux程式的時候，出現segmentation fault是最鬱悶的事情了，程式**量很大的時候，可能花很多時間都找不到出錯原因。
這裡介紹一種對你除錯segmentation fault很有幫助的方法，可能能迅速幫助你找到出錯的**行。
這種方法需要用到linux提供的core dump機制：當程式中出現記憶體操作錯誤時，會發生崩潰並產生核心檔案（core檔案）。使用gdb可以對產生的核心檔案進行分析，找出程式是在什麼時候崩潰的和在崩潰之前程式都做了些什麼。
首先，你的segmentation fault錯誤必須要能重現（廢話…）。
然後，依參照下面的步驟來操作：
（1）無論你是用makefile來編譯，還是直接在命令列手工輸入命令來編譯，都應該加上 -g 選項。
（2）一般來說，在預設情況下，在程式崩潰時，core檔案是不生成的（很多linux發行版在預設時禁止生成核心檔案）。所以，你必須修改這個預設選項，在命令列執行：
ulimit -c unlimited
表示不限制生成的core檔案的大小。
（3）執行你的程式，不管用什麼方法，使之重現segmentation fault錯誤。
（4）這時，你會發現在你程式同一目錄下，生成了乙個檔名為core.***的檔案，即核心檔案。例如，「core.15667」這樣的檔案。
（5）用gdb除錯它。假設你的可執行程式名為test，則在命令列執行：
gdb test core.15667
然後可能會顯示出一堆資訊：
gnu gdb fedora (6.8-27.el5)
license gplv3+: gnu gpl version 3 or later
this is free software: you are free to change and redistribute it.
there is no warranty, to the extent permitted by law. type "show copying"
and "show warranty" for details.
this gdb was configured as "i386-redhat-linux-gnu"...
warning: can't read pathname for load map: input/output error.
…………………（中間還有很多內容，此處省略）……………………………
loaded symbols for /usr/lib/libgpg-error.so.0
core was generated by `./test'.
program terminated with signal 11, segmentation fault.
[new process 15668]
#0 0x0804c760 in thread _handler () at test.cpp:707
707 cdev* cur_dev = *it_d;
然後我們輸入並執行命令
bt：
(gdb) bt
就會得到類似於下面的資訊：
#0 0x0804c760 in thread _handler () at test.cpp:707
#1 0x006b149b in start_thread () from /lib/libpthread.so.0
#2 0x0060842e in clone () from /lib/libc.so.6
於是，我們一眼就看出來了：程式是在第
707行使用指標時出的問題。
怎麼樣，方便吧？
**：
如何檢視core檔案
在unix系統下，應用程式崩潰，一般會產生core檔案，如何根據core檔案查詢問題的所在，並做相應的分析和除錯，是非常重要的，本文對此做簡單介紹。例如，乙個程式cmm test tool在執行的時候發生了錯誤，並生成了乙個core檔案，如下 rw r r 1 root cmm test tool....
core檔案除錯
在程式不尋常退出時，核心會在當前工作目錄下生成乙個core檔案 是乙個記憶體映像，同時加上除錯資訊 使用gdb來檢視core檔案，可以指示出導致程式出錯的 所在檔案和行數。1.core檔案的生成開關和大小限制 1 使用ulimit c命令可檢視core檔案的生成開關。若結果為0，則表示關閉了此功能，...
linux gdb除錯core檔案
uname a linux dev 2.4.21 9.30axsmp 1 smp wed may 26 23 37 09 edt 2004 i686 i686 i386 gnu linux 再看看預設的一些引數，注意core file size是個0，程式出錯時不會產生core檔案了。ulimit ...