這種資訊一般都是由記憶體通路越界造成的,不管是使用者态程式還是核心态程式通路越界都會出core, 并在系統日志裡面輸出一條這樣的資訊。
這條資訊的前面分别是通路越界的程式名,程序ID号,通路越界的位址以及當時程序堆棧位址等資訊,比較有用的資訊是最後的error number. 在上面的資訊中,error number是6,轉成二進制就是110, 即bit2=1, bit1=1, bit0=0, 按照上面的解釋,我們可以得出這條資訊是由于使用者态程式讀操作通路越界造成的:
error number是由三個字位組成的,從高到底分别為bit2 bit1和bit0,是以它的取值範圍是0~7.
bit2: 值為1表示是使用者态程式記憶體通路越界,值為0表示是核心态程式記憶體通路越界
bit1: 值為1表示是寫操作導緻記憶體通路越界,值為0表示是讀操作導緻記憶體通路越界
bit0: 值為1表示沒有足夠的權限通路非法位址的内容,值為0表示通路的非法位址根本沒有對應的頁面,也就是無效位址
記憶體不足不會引起段錯誤,段錯誤通常出現在通路了非法的位址後,非法位址分為3類:
1. 通路的位址沒有對應的實體記憶體。這類錯誤主要出現在越界通路,例如棧越界。比如說目前程序的棧隻有5個頁和它對應,共20k大小(x86平台),你通路的位址超過了這個範圍,就會發生segmentation fault;
2.對位址的操作與該位址的屬性不符合。例如該位址對應的記憶體是隻讀的,如文本段,你卻試圖進行寫操作;
3.低權限通路高權限位址。這類情況發生在使用者程序試圖通路核心空間。例如x86中,TASK_SIZE以上的位址為核心空間,當使用者态程序試圖通路這些位址時,就會出現”segmentation fault“了
具體格式如下:
<a href="http://blog.51cto.com/attachment/201304/175809978.jpg" target="_blank"></a>
解決方法:
readelf -s a.out 可以檢視符号表,根據rip所指的位址就能找到對應的函數了。
objdump -d a.out > a.s 可以反彙編,不但能找到函數,還能直接定位到指令。
注:本人測試沒找到map檔案(即a.out),故報錯的程式和函數并未找到,有找到的博友可以回複告知操作過程,在此謝過!
另附上老外的原了解釋:
Well the rip pointer tells you the instruction that caused the crash. You need to look it up in a map file.
In the map file you will have a list of functions and their starting address. When you load the application it is loaded to a base address.
The rip pointer - the base address gives you the map file address. If you then search through the map file for a function that starts at
an address slightly lower than your rip pointer and is followed, in the list, by a function with a higher address you have located the function that crashed.
From there you need to try and identify what went wrong in your code. Its not much fun but it, at least, gives you a starting point.
Edit: The "segfault at" bit is telling you, i'd wager, that you have dereferenced a NULL pointer. The rsp is the current stack pointer.
Alas its probably not all that useful. With a memory dump you "may" be able to figure out more accurately where you'd got to in the function
but it can be really hard to work out, exactly, where you are in an optimised build
本文轉自 xxrenzhe11 51CTO部落格,原文連結:http://blog.51cto.com/xxrenzhe/1185915,如需轉載請自行聯系原作者