今天在Linux下調試C程序時,出現段錯誤,習慣性的ls下當前目錄,發現沒有生成core文件。驚訝了一下,怎么回事?以前都會產生的啊,難不成是程序的問題?后來同事提醒是不是系統沒有打開生成core dump的設置。
還真是系統設置問題,我的ubuntu14.04是新裝的,之前沒有進行過core dump的相關配置,別急!我們來看看怎么對linux系統設置當程序出現段錯誤時產生core文件:
1、先用#ulimit -a可以查看系統core文件的大小限制(第一行),core文件大小設置為0, 即沒有打開core dump設置;
root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 46621
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 46621
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
2、接下來使用#ulimit -c [kbytes]可以設置系統允許生成的core文件大小;
ulimit -c 0 不產生core文件
ulimit -c 100 設置core文件最大為100k
ulimit -c unlimited 不限制core文件大小
執行#ulimit -c unlimited,然后#ulimit -a查看結果如下(第一行):
root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 46621
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 46621
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
此時,core dump設置打開了,再執行程序出現段錯誤時,在當前工作目錄下產生了core文件,然后我們就可以用gdb調試core文件了。
例如:
gdb ./test core.2065
注:Linux下的C程序常常會因為內存訪問錯誤等原因造成segment fault(段錯誤),此時如果系統core dump功能是打開的,那么將會有內存映像轉儲到硬盤上來,之后可以用gdb對core文件進行分析,還原系統發生段錯誤時刻的堆棧情況。這對于我們發現程序bug很有幫助。
很多系統默認的core文件大小都是0,我們可以通過在shell的啟動腳本/etc/bashrc或者~/.bashrc等地方來加入 ulimit -c 命令來指定core文件大小,從而確保core文件能夠生成。
除此之外,還可以在/proc/sys/kernel/core_pattern里設置core文件的文件名模板,詳情請看core的官方man手冊。
需要說明的是:上述方法只是在當前shell中生效,重啟之后,就不再有效了。永久生效的辦法是如下:
永久生效辦法:
#vi /etc/profile 然后,在profile中添加:
ulimit -c 1073741824
(但是,若將產生的轉儲文件大小大于該數字時,將不會產生轉儲文件)
或者
ulimit -c unlimited
這樣重啟機器后生效了。 或者, 使用source命令使之馬上生效。
source /etc/profile
三、指定內核轉儲的文件名和目錄
修改完內核轉儲設置后,當程序core dump后發現確實在本地目錄產生了core文件,但是如果程序多次core dump時,core文件會被覆蓋,原因是每次core dump后生成的文件名默認都叫core,接下來就分享下如果想在每次core dum時產生的core文件都帶上進程號怎么操作,或者你想把內核轉儲文件保存到其他目錄怎么辦?
1、core dump文件名自動加上進程ID
echo 1 > /proc/sys/kernel/core_uses_pid
最后生成的core dump文件名會加上進程ID.
2、另外可以通過修改kernel的參數,指定內核轉儲所生成的core文件的路徑和文件名。
可以通過在/etc/sysctl.conf文件中,對sysctl變量kernel.core_pattern的設置。
#vim /etc/sysctl.conf 然后,在sysctl.conf文件中添加下面兩句話:
```
kernel.core_pattern = /var/core/core_%e_%p
kernel.core_uses_pid = 0
```
保存后退出。
注:如果/proc/sys/kernel/core_uses_pid 這個文件的內容被配置成1,即使core_pattern中沒有設置%p,最后生成的core dump文件名仍會加上進程ID。
這里%e, %p分別表示:
%c 轉儲文件的大小上限
%e 所dump的文件名
%g 所dump的進程的實際組ID
%h 主機名
%p 所dump的進程PID
%s 導致本次coredump的信號
%t 轉儲時刻(由1970年1月1日起計的秒數)
%u 所dump進程的實際用戶ID
可以使用以下命令,使修改結果馬上生效。
sysctl –p /etc/sysctl.conf
請在/var目錄下先建立core文件夾,然后執行a.out程序,就會在/var/core/下產生以指定格式命名的內核轉儲文件。查看轉儲文件的情況:
ls /var/core
```
core_a.out_2456
```
更詳細的內容或手動強制某個進程產生core dump的方法見鏈接:http://blog.csdn.net/wj_j2ee/article/details/7161586
幫助鏈接:http://www.cppblog.com/API/archive/2012/10/22/193644.html
————————————————
版權聲明:本文為CSDN博主「不會游泳的魚star」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/star_xiong/article/details/43529637
- 前言
- 服務器開發設計
- Reactor模式
- 一種心跳,兩種設計
- 聊聊 TCP 長連接和心跳那些事
- 學習TCP三次握手和四次揮手
- Linux基礎
- Linux的inode的理解
- 異步IO模型介紹
- 20個最常用的GCC編譯器參數
- epoll
- epoll精髓
- epoll原理詳解及epoll反應堆模型
- epoll的坑
- epoll的本質
- socket的SO_REUSEADDR參數全面分析
- 服務器網絡
- Protobuf
- Protobuf2 語法指南
- 一種自動反射消息類型的 Protobuf 網絡傳輸方案
- 微服務
- RPC框架
- 什么是RPC
- 如何科學的解釋RPC
- RPC 消息協議
- 實現一個極簡版的RPC
- 一個基于protobuf的極簡RPC
- 如何基于protobuf實現一個極簡版的RPC
- 開源RPC框架
- thrift
- grpc
- brpc
- Dubbo
- 服務注冊,發現,治理
- Redis
- Redis發布訂閱
- Redis分布式鎖
- 一致性哈希算法
- Redis常見問題
- Redis數據類型
- 緩存一致性
- LevelDB
- 高可用
- keepalived基本理解
- keepalived操做
- LVS 學習
- 性能優化
- Linux服務器程序性能優化方法
- SRS性能(CPU)、內存優化工具用法
- centos6的性能分析工具集合
- CentOS系統性能工具 sar 示例!
- Linux性能監控工具集sysstat
- gdb相關
- Linux 下如何產生core文件(core dump設置)