鏡像下載、域名解析、時間同步請點(diǎn)擊 阿里云開源鏡像站
作為一個半路出家的linuc用戶，coredump這個問題太讓人抓狂了，網(wǎng)上找了好多都是不全面，不適應(yīng)或者看不懂；現(xiàn)在終于解決了，記錄一下防止以后出現(xiàn)還是無解，同時也分享給大家，希望大家能少踩一些坑。
1.什么是段錯誤
core dump又叫核心轉(zhuǎn)儲, 當(dāng)程序運(yùn)行過程中發(fā)生異常, 程序異常退出時, 由操作系統(tǒng)把程序當(dāng)前的內(nèi)存狀況存儲在一個core文件中, 叫core dump. (linux中如果內(nèi)存越界會收到SIGSEGV信號，然后就會core dump)。產(chǎn)生段錯誤的原因大致上有三類：訪問不存在的內(nèi)存地址、訪問系統(tǒng)保護(hù)的內(nèi)存地址和訪問只讀的內(nèi)存地址。
2. 解決方案
網(wǎng)上的資料雖然比較亂，但是也提供了一個解決問題的思路：
(1)設(shè)置core文件，找到段錯誤生成的core文件
(2)利用core文件，使用GDB測試找到問題所在
3.解決過程
先看問題：
3.1 生成Core文件
3.1.1 使用ulimit -a命令查看core文件大小限制
可以看到core file size的大小為0，文件根本裝不進(jìn)，需要使用 ulimit -c unlimited 修改這個文件的大小
修改成功后，按照網(wǎng)上的說法，再運(yùn)行程序就會生成core文件，一般路徑和可執(zhí)行程序一個路徑。但是在ubuntu20.04下，怎么也找不到去哪里了（反正我的是這樣），因此需要查看core文件的生成路徑。
3.1.2 在終端輸入 cat /proc/sys/kernel/core_pattern 查看core的生成路徑。
轉(zhuǎn)到這個路徑下去找是找不到core文件，這是因?yàn)閡buntu的服務(wù)apport.service。自動生成崩潰報(bào)告，官方為了自動收集錯誤的。我們肯定想到修改路徑的辦法，那就演示一下會怎么樣。
core的設(shè)置主要有兩個命令：
//控制core文件的文件名中是否添加pid作為擴(kuò)展
echo "1" > /proc/sys/kernel/core_uses_pid
//設(shè)置core文件的輸出路徑和輸出文件名，這里我的路徑是/home/boy/corefile，文件名就是后面的部分
echo "/home/boy/corefile/core-%e-%p-%t"> /proc/sys/kernel/core_pattern
//參數(shù)說明
%p - insert pid into filename 添加pid
%u - insert current uid into filename 添加當(dāng)前uid
%g - insert current gid into filename 添加當(dāng)前gid
%s - insert signal that caused the coredump into the filename 添加導(dǎo)致產(chǎn)生core的信號
%t - insert UNIX time that the coredump occurred into filename 添加core文件生成時的unix時間
%h - insert hostname where the coredump happened into filename 添加主機(jī)名
%e - insert coredumping executable name into filename 添加程序名
我直接用echo "/home/boy/corefile/core-%e-%p-%t"> /proc/sys/kernel/core_pattern 進(jìn)行修改，結(jié)果如圖
3.1.3 修改core文件生成路徑
因?yàn)槲覀冃薷牡腸ore_pattern文件是只讀文件，沒法這樣修改。所以要換一種思路，修改不了就先停掉apport.service，這個服務(wù)對我們來說基本沒用。
錯誤報(bào)告的部分操作命令如下：
//1.啟用錯誤報(bào)告
sudo systemctl enable apport.service
//或
sudo service apport start
//2.關(guān)閉錯誤報(bào)告
sudo systemctl disable apport.service
//或
sudo service apport stop
所以，用sudo service apport stop關(guān)閉錯誤報(bào)告后我們再看core文件的路徑會怎么樣
可以看到，路徑發(fā)生了變化，再運(yùn)行一次試試，看現(xiàn)在能不能生成core
可以看到，運(yùn)行完后用ll查看生成了core文件，方法有限，下面就是GDB調(diào)試找到錯誤的位置了。
3.2 GDB測試
GDB詳細(xì)說明請看參考資料大佬的整理，這里只記錄一下我怎么測試的
3.2.1 啟動gdb
輸入gdb 運(yùn)行文件 core文件,例如：
gdb bin/run_vo core
結(jié)果如下：
可以看到對內(nèi)存出現(xiàn)非法訪問時將收到段錯誤信號SIGSEGV下面就是出錯的位置，我們還可以使用backtrace回溯定位問題。
3.2.2 輸入bt回溯定位
可以看到現(xiàn)在的報(bào)告更加詳細(xì)。
到此，coredump問題已經(jīng)解決，輸入q,即可退出gdb,剩下就是修改問題部分了。
原文鏈接：https://blog.csdn.net/weixin_52402390/article/details/123900689
