調試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)
Copyright (C) 2008 Free Software Foundation, Inc.
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行使用指針時出的問題。 怎麼樣，方便吧？
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/learnhard/archive/2009/11/26/4879834.aspx
