Ubuntu20.04出現段錯誤核心已轉儲問題解決方案

映象下載、域名解析、時間同步請點選  阿里雲開源映象站

作為一個半路出家的linuc使用者，coredump這個問題太讓人抓狂了，網上找了好多都是不全面，不適應或者看不懂；現在終於解決了，記錄一下防止以後出現還是無解，同時也分享給大家，希望大家能少踩一些坑。

1.什麼是段錯誤

core dump又叫核心轉儲, 當程式執行過程中發生異常, 程式異常退出時, 由作業系統把程式當前的記憶體狀況儲存在一個core檔案中, 叫core dump. (linux中如果記憶體越界會收到SIGSEGV訊號，然後就會core dump)。產生段錯誤的原因大致上有三類： 訪問不存在的記憶體地址、訪問系統保護的記憶體地址和訪問只讀的記憶體地址。

2. 解決方案

網上的資料雖然比較亂，但是也提供了一個解決問題的思路：

(1)設定core檔案，找到段錯誤生成的core檔案

(2)利用core檔案，使用GDB測試找到問題所在

3.解決過程

先看問題：

3.1 生成Core檔案

3.1.1 使用ulimit -a命令檢視core檔案大小限制

可以看到core file size的大小為0，檔案根本裝不進，需要使用 ulimit -c unlimited 修改這個檔案的大小

修改成功後，按照網上的說法，再執行程式就會生成core檔案，一般路徑和可執行程式一個路徑。但是在ubuntu20.04下，怎麼也找不到去哪裡了（反正我的是這樣），因此需要檢視core檔案的生成路徑。

3.1.2 在終端輸入 cat /proc/sys/kernel/core_pattern 檢視core的生成路徑。

轉到這個路徑下去找是找不到core檔案，這是因為ubuntu的服務apport.service。自動生成崩潰報告，官方為了自動收集錯誤的。我們肯定想到修改路徑的辦法，那就演示一下會怎麼樣。

core的設定主要有兩個命令：

 //控制core檔案的檔名中是否新增pid作為擴充套件
echo "1" > /proc/sys/kernel/core_uses_pid  
//設定core檔案的輸出路徑和輸出檔名，這裡我的路徑是/home/boy/corefile，檔名就是後面的部分
echo "/home/boy/corefile/core-%e-%p-%t"> /proc/sys/kernel/core_pattern 
 
//引數說明
%p - insert pid into filename 新增pid
%u - insert current uid into filename 新增當前uid
%g - insert current gid into filename 新增當前gid
%s - insert signal that caused the coredump into the filename 新增導致產生core的訊號
%t - insert UNIX time that the coredump occurred into filename 新增core檔案生成時的unix時間
%h - insert hostname where the coredump happened into filename 新增主機名
%e - insert coredumping executable name into filename 新增程式名

我直接用echo “/home/boy/corefile/core-%e-%p-%t”> /proc/sys/kernel/core_pattern 進行修改，結果如圖

3.1.3 修改core檔案生成路徑

因為我們修改的core_pattern檔案是隻讀檔案，沒法這樣修改。所以要換一種思路，修改不了就先停掉apport.service，這個服務對我們來說基本沒用。

錯誤報告的部分操作命令如下：

//1.啟用錯誤報告
sudo systemctl enable apport.service
//或
sudo service apport start
 
//2.關閉錯誤報告
sudo systemctl disable apport.service
//或
sudo service apport stop

所以，用sudo service apport stop關閉錯誤報告後我們再看core檔案的路徑會怎麼樣

可以看到，路徑發生了變化，再執行一次試試，看現在能不能生成core

可以看到，執行完後用ll檢視生成了core檔案，方法有限，下面就是GDB除錯找到錯誤的位置了。

3.2 GDB測試

GDB詳細說明請看參考資料大佬的整理，這裡只記錄一下我怎麼測試的

3.2.1 啟動gdb

輸入gdb 執行檔案 core檔案,例如：

gdb  bin/run_vo  core

結果如下：

可以看到對記憶體出現非法訪問時將收到段錯誤訊號SIGSEGV下面就是出錯的位置，我們還可以使用backtrace回溯定位問題。

3.2.2 輸入bt回溯定位

可以看到現在的報告更加詳細。

到此，coredump問題已經解決，輸入q,即可退出gdb,剩下就是修改問題部分了。

原文連結：https://blog.csdn.net/weixin_52402390/article/details/123900689