目錄
1 問題原因
Segmentation fault (core dumped)多爲內存不當操作造成。空指針、野指針的讀寫操作，數組越界訪問，破壞常量等。對每個指針聲明後進行初始化爲NULL是避免這個問題的好辦法。排除此問題的最好辦法則是調試。
更爲詳細的原因：
（1）內存訪問越界
a) 由於使用錯誤的下標，導致數組訪問越界
b) 搜索字符串時，依靠字符串結束符來判斷字符串是否結束，但是字符串沒有正常的使用結束符
c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函數，將目標字符串讀/寫爆。應該使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函數防止讀寫越界。
（2）多線程程序使用了線程不安全的函數。
（3）多線程讀寫的數據未加鎖保護。
對於會被多個線程同時訪問的全局數據，應該注意加鎖保護，否則很容易造成core dump
（4）非法指針a) 使用空指針
b) 隨意使用指針轉換。一個指向一段內存的指針，除非確定這段內存原先就分配爲某種結構或類型，或者這種結構或類型的數組，否則不要將它轉換爲這種結構或類型的指針，而應該將這段內存拷貝到一個這種結構或類型中，再訪問這個結構或類型。這是因爲如果這段內存的開始地址不是按照這種結構或類型對齊的，那麼訪問它時就很容易因爲bus error而core dump.
（5）堆棧溢出。
不要使用大的局部變量（因爲局部變量都分配在棧上），這樣容易造成堆棧溢出，破壞系統的棧和堆結構，導致出現莫名其妙的錯誤。
2 使用GDB查看core文件
默認編譯出來的程序在出現Segmentation fault 時並沒有生成core崩潰文件，可以在gcc/g++編譯時增加-g選項。
如果仍然沒有生成core文件，則可能是因爲系統設置了core文件大小爲0，可以通過：ulimit -a 查詢得知。
執行 ulimit -c unlimited 命令後可以使core文件大小不受限制。此時再次運行程序應該就能在同級目錄看到core.XXX文件了
使用 gdb ./a.out core.XXX 可以查看出錯所在行信息，這樣就進入了 gdb core 調試模式。
追蹤產生segmenttation fault的位置及代碼函數調用情況：
gdb>bt
這樣，一般就可以看到出錯的代碼是哪一句了，還可以打印出相應變量的數值，進行進一步分析。
3 使用GDB調試程序
如上述流程不能解決問題，下面可使用gdb單步調試程序。重新編譯程序，編譯命令中加入-g。如：
gcc -lm -O3 -g file.c -o file
之後使用gdb命令
gdb file
開始調試。
輸入start使程序運行到main中第一行運行代碼。next或者n爲執行下一行程序，until xx執行到xx行，print或p可輸出變量值，b xx用於在xx行設置斷點，run或r用於執行程序至下一斷點，d xx刪除xx行斷點。
我們可以先run一遍程序，這時它會提示出錯行信息。然後until到出錯行前5行，交替執行next和print，輸出與出錯行變量相關變量或指針的值。最終定位出錯的根本操作在哪一行。修改之即可。
