如何查看Core文件(通用)

如何查看Core文件(通用)

場景(Ubuntu 16.04):

我編譯並運行一個C程式(使用-g,我得到傳統的Segmentation Fault (core dumped),然後(當然)沒有找到神話般的“核心”文件。一些挖掘說用/proc/sys/kernel/core_pattern命令修改以達到以下效果:echo '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_pattern,然後做完對此,我停止獲取並開始只獲取.的(core dumped)普通Segmentation Faultgdb ./program_object_file.out core.pidgdb ./a.out(gdb) core core.pidtab

問題:

有沒有通用的方法可以獲得核心轉儲?我認識到我接觸到的每台機器似乎都有一個邁克爾貝的變形金剛-esque 重新配置硬體和軟體的能力,這樣我擁有的任何設備都不能開箱即用正常工作。是否有一個簡單的演算法/方法可以讓我在自己的機器以及其他人的機器上找到核心轉儲?我總是發現自己在做了大量的工作之後就這樣的事情輔導朋友,讓事情為自己工作,如果能夠運行命令或其他東西來將核心文件轉儲到運行可執行文件的目錄中,那就太好了...有什麼方法可以在大多數(我會滿足於“某些”)Linux/Unix 機器上執行此操作嗎?

答案1

core(5)線上幫助頁詳細描述了影響核心轉儲的參數,包括它們的命名等。

為了回答您提出的問題,沒有通用的方法來尋找核心轉儲。預設情況下,核心轉儲到流程的當前工作目錄,如果允許進程在那裡寫入,如果包含的檔案系統上有足夠的空間,如果沒有現有的核心轉儲(在某些情況下),以及檔案大小和核心檔案大小限制(由ulimit或類似的機制)允許它。但/proc/sys/kernel/core_pattern提供了許多不同的處理核心轉儲的方法,因此您確實也需要查看並弄清楚發生了什麼。

在你的情況下,我不知道為什麼最初找不到核心,但我知道為什麼你在設定重定向後停止獲取核心:當在 中使用管道時core_pattern,處理程序必須使用絕對路徑名指定。tee單獨使用不會被使用;你需要指定/usr/bin/tee.請注意,您應該特別注意多用戶系統上的此類設置,因為處理核心轉儲的程式運行為root.

在 Debian 衍生品上我安裝corekeeper,它以易於使用的方式將核心轉儲寫入/var/crash.

答案2

(將問題中的答案從OP移至答案)

我將下面的答案標記為正確答案,因為它幫助我確定實際出了什麼問題,我想在將來返回以進一步充實這一點,但我目前的解決方案(我懷疑它適用於大多數情況) Linux 機器)是使用以下命令 -

cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak 
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern

這會將您先前的核心轉儲方法備份到.core_pattern.bak主資料夾中的隱藏檔案 ( ) 中,可以使用下列命令還原該文件

sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern

第二個指令將導致核心轉儲轉儲到core名為dump.顯然,您可以修改此格式以獲得更符合您喜好的模式。然而,應該指出的是,據我所知,這次只會儲存一個核心轉儲(每個新的都會破壞舊的),但因為,如果我個人檢查過核心轉儲,它是為了剛剛運行的程序,並且由於我不需要保留舊的轉儲,這對我和我的朋友將要創建和調試的大多數應用程式來說是一個很好的解決方案。我很想進一步修改這個答案,以包括諸如導致段錯誤的PID之類的內容(主要只是頂部的糖,因為-再次-我通常知道哪個程序導致了段錯誤,因為我剛剛運行了它)但是這個對我和我想像的許多人來說肯定足夠了。

最後但並非最不重要的一點是,要實際查看轉儲,只需執行以下命令:

gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump

假設您位於編譯/執行出現段錯誤的可執行檔的資料夾中。

相關內容