您好,登錄后才能下訂單哦!
這篇文章主要介紹了在Linux上怎么得到一個段錯誤的核心轉(zhuǎn)儲,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
“段錯誤”是指你的程序嘗試訪問不允許訪問的內(nèi)存地址的情況。這可能是由于:
試圖解引用空指針(你不被允許訪問內(nèi)存地址 0
);
試圖解引用其他一些不在你內(nèi)存(LCTT 譯注:指不在合法的內(nèi)存地址區(qū)間內(nèi))中的指針;
一個已被破壞并且指向錯誤的地方的
C++ 虛表指針,這導(dǎo)致程序嘗試執(zhí)行沒有執(zhí)行權(quán)限的內(nèi)存中的指令;
其他一些我不明白的事情,比如我認(rèn)為訪問未對齊的內(nèi)存地址也可能會導(dǎo)致段錯誤(LCTT 譯注:在要求自然邊界對齊的體系結(jié)構(gòu),如 MIPS、ARM 中更容易因非對齊訪問產(chǎn)生段錯誤)。
這個“C++ 虛表指針”是我的程序發(fā)生段錯誤的情況。我可能會在未來的博客中解釋這個,因為我最初并不知道任何關(guān)于 C++ 的知識,并且這種虛表查找導(dǎo)致程序段錯誤的情況也是我所不了解的。
但是!這篇博客后不是關(guān)于 C++ 問題的。讓我們談?wù)摰幕镜臇|西,比如,我們?nèi)绾蔚玫揭粋€核心轉(zhuǎn)儲?
我發(fā)現(xiàn)找出為什么我的程序出現(xiàn)段錯誤的最簡單的方式是使用 valgrind
:我運行
valgrind -v your-program
這給了我一個故障時的堆棧調(diào)用序列。 簡潔!
但我想也希望做一個更深入調(diào)查,并找出些 valgrind
沒告訴我的信息! 所以我想獲得一個核心轉(zhuǎn)儲并探索它。
核心轉(zhuǎn)儲是您的程序內(nèi)存的一個副本,并且當(dāng)您試圖調(diào)試您的有問題的程序哪里出錯的時候它非常有用。
當(dāng)您的程序出現(xiàn)段錯誤,Linux 的內(nèi)核有時會把一個核心轉(zhuǎn)儲寫到磁盤。 當(dāng)我最初試圖獲得一個核心轉(zhuǎn)儲時,我很長一段時間非常沮喪,因為 - Linux 沒有生成核心轉(zhuǎn)儲!我的核心轉(zhuǎn)儲在哪里?
這就是我最終做的事情:
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)
在啟動我的程序之前運行 ulimit -c unlimited
運行 sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
ulimit -c
設(shè)置核心轉(zhuǎn)儲的***尺寸。 它往往設(shè)置為 0,這意味著內(nèi)核根本不會寫核心轉(zhuǎn)儲。 它以千字節(jié)為單位。 ulimit
是按每個進(jìn)程分別設(shè)置的 —— 你可以通過運行 cat /proc/PID/limit
看到一個進(jìn)程的各種資源限制。
例如這些是我的系統(tǒng)上一個隨便一個 Firefox 進(jìn)程的資源限制:
$ cat /proc/6309/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 30571 30571 processes Max open files 1024 1048576 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 30571 30571 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us
內(nèi)核在決定寫入多大的核心轉(zhuǎn)儲文件時使用軟限制(在這種情況下,max core file size = 0
)。 您可以使用 shell 內(nèi)置命令 ulimit
(ulimit -c unlimited
) 將軟限制增加到硬限制。
kernel.core_pattern
是一個內(nèi)核參數(shù),或者叫 “sysctl 設(shè)置”,它控制 Linux 內(nèi)核將核心轉(zhuǎn)儲文件寫到磁盤的哪里。
內(nèi)核參數(shù)是一種設(shè)定您的系統(tǒng)全局設(shè)置的方法。您可以通過運行 sysctl -a
得到一個包含每個內(nèi)核參數(shù)的列表,或使用 sysctl kernel.core_pattern
來專門查看 kernel.core_pattern
設(shè)置。
所以 sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
將核心轉(zhuǎn)儲保存到目錄 /tmp
下,并以 core
加上一系列能夠標(biāo)識(出故障的)進(jìn)程的參數(shù)構(gòu)成的后綴為文件名。
如果你想知道這些形如 %e
、%p
的參數(shù)都表示什么,請參考 man core。
有一點很重要,kernel.core_pattern
是一個全局設(shè)置 —— 修改它的時候***小心一點,因為有可能其它系統(tǒng)功能依賴于把它被設(shè)置為一個特定的方式(才能正常工作)。
默認(rèn)情況下在 ubuntu 系統(tǒng)中,kernel.core_pattern
被設(shè)置為下面的值:
$ sysctl kernel.core_patternkernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P
這引起了我的迷惑(這 apport 是干什么的,它對我的核心轉(zhuǎn)儲做了什么?)。以下關(guān)于這個我了解到的:
Ubuntu 使用一種叫做 apport 的系統(tǒng)來報告 apt 包有關(guān)的崩潰信息。
設(shè)定 kernel.core_pattern=|/usr/share/apport/apport %p %s %c %d %P
意味著核心轉(zhuǎn)儲將被通過管道送給 apport
程序。
apport 的日志保存在文件 /var/log/apport.log
中。
apport 默認(rèn)會忽略來自不屬于 Ubuntu 軟件包一部分的二進(jìn)制文件的崩潰信息
我最終只是跳過了 apport,并把 kernel.core_pattern
重新設(shè)置為 sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
,因為我在一臺開發(fā)機(jī)上,我不在乎 apport 是否工作,我也不想嘗試讓 apport 把我的核心轉(zhuǎn)儲留在磁盤上。
好的,現(xiàn)在我們了解了 ulimit
和 kernel.core_pattern
,并且實際上在磁盤的 /tmp
目錄中有了一個核心轉(zhuǎn)儲文件。太好了!接下來干什么?我們?nèi)匀徊恢涝摮绦驗槭裁磿霈F(xiàn)段錯誤!
下一步將使用 gdb
打開核心轉(zhuǎn)儲文件并獲取堆棧調(diào)用序列。
你可以像這樣用 gdb
打開一個核心轉(zhuǎn)儲文件:
$ gdb -c my_core_file
接下來,我們想知道程序崩潰時的堆棧是什么樣的。在 gdb
提示符下運行 bt
會給你一個調(diào)用序列。在我的例子里,gdb
沒有為二進(jìn)制文件加載符號信息,所以這些函數(shù)名就像 “??????”。幸運的是,(我們通過)加載符號修復(fù)了它。
下面是如何加載調(diào)試符號。
symbol-file /path/to/my/binarysharedlibrary
這從二進(jìn)制文件及其引用的任何共享庫中加載符號。一旦我這樣做了,當(dāng)我執(zhí)行 bt
時,gdb 給了我一個帶有行號的漂亮的堆棧跟蹤!
如果你想它能工作,二進(jìn)制文件應(yīng)該以帶有調(diào)試符號信息的方式被編譯。在試圖找出程序崩潰的原因時,堆棧跟蹤中的行號非常有幫助。:)
通過以下方式在 gdb
中獲取每個線程的調(diào)用棧!
thread apply all bt full
如果你有一個帶調(diào)試符號的核心轉(zhuǎn)儲以及 gdb
,那太棒了!您可以上下查看調(diào)用堆棧(LCTT 譯注:指跳進(jìn)調(diào)用序列不同的函數(shù)中以便于查看局部變量),打印變量,并查看內(nèi)存來得知發(fā)生了什么。這是***的。
如果您仍然正在基于 gdb 向?qū)砉ぷ魃?,只打印出棧跟蹤與bt也可以。 :)
另一種搞清楚您的段錯誤的方法是使用 AddressSanitizer 選項編譯程序(“ASAN”,即 $CC -fsanitize=address
)然后運行它。 本文中我不準(zhǔn)備討論那個,因為本文已經(jīng)相當(dāng)長了,并且在我的例子中打開 ASAN 后段錯誤消失了,可能是因為 ASAN 使用了一個不同的內(nèi)存分配器(系統(tǒng)內(nèi)存分配器,而不是 tcmalloc)。
在未來如果我能讓 ASAN 工作,我可能會多寫點有關(guān)它的東西。(LCTT 譯注:這里指使用 ASAN 也能復(fù)現(xiàn)段錯誤)
聽起來很多,當(dāng)我做這些的時候很困惑,但說真的,從一個段錯誤的程序中獲得一個堆棧調(diào)用序列不需要那么多步驟:
試試用 valgrind
如果那沒用,或者你想要拿到一個核心轉(zhuǎn)儲來調(diào)查:
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)
確保二進(jìn)制文件編譯時帶有調(diào)試符號信息;
正確的設(shè)置 ulimit
和 kernel.core_pattern
;
運行程序;
一旦你用 gdb
調(diào)試核心轉(zhuǎn)儲了,加載符號并運行 bt
;
嘗試找出發(fā)生了什么!
感謝你能夠認(rèn)真閱讀完這篇文章,希望小編分享的“在Linux上怎么得到一個段錯誤的核心轉(zhuǎn)儲”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關(guān)注億速云行業(yè)資訊頻道,更多相關(guān)知識等著你來學(xué)習(xí)!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。