標籤:
本文轉載自:http://blog.csdn.net/learnhard/article/details/4879834
調試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 <http://gnu.org/licenses/gpl.html>
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行使用指標時出的問題。
怎麼樣,方便吧?
用GDB調試Segmentation 段錯誤【轉】