小結 Coredump 之Segmentation faults(段錯誤) 以及調試和解決方法

 先看一些基本的知識:html

那什麼是段錯誤?段錯誤爲何是個麻煩事?以及怎麼發現程序中的段錯誤以及如何避免發生段錯誤呢?node


   1.什麼是段錯誤?
  linux

   下面是來自Answers.com的定義:
程序員

A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors.

Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.

On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception.sql


另外,這裏有個基本上對照的中文解釋,來自 http://www.linux999.org/html_sql/3/132559.htm

所謂的段錯誤就是指訪問的內存超出了系統所給這個程序的內存空間,一般這個值是由gdtr來保存的,他是一個48位的寄存器,其中的32位是保存由它指向的gdt表,後13位保存相應於gdt的下標,最後3位包括了程序是否在內存中以及程序的在cpu中的運行級別,指向的gdt是由以64位爲一個單位的表,在這張表中就保存着程序運行的代碼段以及數據段的起始地址以及與此相應的段限和頁面交換還有程序運行級別還有內存粒度等等的信息。一旦一個程序發生了越界訪問,cpu就會產生相應的異常保護,因而segmentation fault就出現了編程



經過上面的解釋,段錯誤應該就是訪問了不可訪問的內存,這個內存區要麼是不存在的,要麼是受到系統保護的。

2.編程中一般碰到段錯誤的地方有哪些?windows

1)往受到系統保護的內存地址寫數據

    有些內存是內核佔用的或者是其餘程序正在使用,爲了保證系統正常工做,因此會受到系統的保護,而不能任意訪問。
   數組

   好比對內存地址爲0的空間進行操做就會出現這樣的問題。app

2)內存越界(數組越界,變量類型不一致等)函數

3)其餘

其實大概的緣由都是同樣的,就是段錯誤的定義。可是更多的容易出錯的地方就要本身不斷積累,不段發現,或者吸納前人已經積累的經驗,而且注意避免再次發生。

例如:

<1>定義了指針後記得初始化,在使用的時候記得判斷是否爲NULL
<2>在使用數組的時候是否被初始化,數組下標是否越界,數組元素是否存在等
<3>在變量處理的時候變量的格式控制是否合理等

<4>字符串拷貝(strcpy)時必定要檢查是否越界,是否會出現內存空間不存在的狀況,這種狀況在實際的編程狀況中常常出現。

 

三、解決和調試錯誤信息的一些示例:

在UNIX和類UNIX的環境下,支持調試的工具經常使用的有dbx和gdb,掌握這兩種工具的使用方法能夠大大幫助咱們解決coredump的問題。
下面引用別人的一些示例:

  

 

      咱們在用C/C++語言寫程序的時侯,內存管理的絕大部分工做都是須要咱們來作的。實際上,內存管理是一個比較繁瑣的工做,不管你多高明,經驗多豐富,不免會在此處犯些小錯誤,而一般這些錯誤又是那麼的淺顯而易於消除。可是手工「除蟲」(debug),每每是效率低下且讓人厭煩的,本文將就"段錯誤"這個內存訪問越界的錯誤談談如何快速定位這些"段錯誤"的語句。
下面將就如下的一個存在段錯誤的程序介紹幾種調試方法:

     1  dummy_function (void)
     2  {
     3          unsigned char *ptr = 0x00;
     4          *ptr = 0x00;
     5  }
     6
     7  int main (void)
     8  {
     9          dummy_function ();
    10
    11          return 0;
    12  }

做爲一個熟練的C/C++程序員,以上代碼的bug應該是很清楚的,由於它嘗試操做地址爲0的內存區域,而這個內存區域一般是不可訪問的禁區,固然就會出錯了。咱們嘗試編譯運行它:

xiaosuo@gentux test $ ./a.out
段錯誤

果真不出所料,它出錯並退出了。
1.利用gdb逐步查找段錯誤:
這種方法也是被大衆所熟知並普遍採用的方法,首先咱們須要一個帶有調試信息的可執行程序,因此咱們加上「-g -rdynamic"的參數進行編譯,而後用gdb調試運行這個新編譯的程序,具體步驟以下:

xiaosuo@gentux test $ gcc -g -rdynamic d.c
xiaosuo@gentux test $ gdb ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r
Starting program: /home/xiaosuo/test/a.out

Program received signal SIGSEGV, Segmentation fault.
0x08048524 in dummy_function () at d.c:4
4               *ptr = 0x00;
(gdb)                       

哦?!好像不用一步步調試咱們就找到了出錯位置d.c文件的第4行,其實就是如此的簡單。
從這裏咱們還發現進程是因爲收到了SIGSEGV信號而結束的。經過進一步的查閱文檔(man 7 signal),咱們知道SIGSEGV默認handler的動做是打印」段錯誤"的出錯信息,併產生Core文件,由此咱們又產生了方法二。
2.分析Core文件:
Core文件是什麼呢?

The  default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process's memory  at the time of termination.  A list of the signals which cause a process to dump core can be found in signal(7).

以上資料摘自man page(man 5 core)。不過奇怪了,個人系統上並無找到core文件。後來,憶起爲了漸少系統上的拉圾文件的數量(本人有些潔癖,這也是我喜歡Gentoo的緣由之一),禁止了core文件的生成,查看了如下果然如此,將系統的core文件的大小限制在512K大小,再試:

xiaosuo@gentux test $ ulimit -c
0
xiaosuo@gentux test $ ulimit -c 1000
xiaosuo@gentux test $ ulimit -c
1000
xiaosuo@gentux test $ ./a.out
段錯誤 (core dumped)
xiaosuo@gentux test $ ls
a.out  core  d.c  f.c  g.c  pango.c  test_iconv.c  test_regex.c

core文件終於產生了,用gdb調試一下看看吧:

xiaosuo@gentux test $ gdb ./a.out core
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".


warning: Can't read pathname for load map: 輸入/輸出錯誤.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x08048524 in dummy_function () at d.c:4
4               *ptr = 0x00;

哇,好歷害,仍是一步就定位到了錯誤所在地,佩服一下Linux/Unix系統的此類設計。
接着考慮下去,之前用windows系統下的ie的時侯,有時打開某些網頁,會出現「運行時錯誤」,這個時侯若是剛好你的機器上又裝有windows的編譯器的話,他會彈出來一個對話框,問你是否進行調試,若是你選擇是,編譯器將被打開,並進入調試狀態,開始調試。
Linux下如何作到這些呢?個人大腦飛速地旋轉着,有了,讓它在SIGSEGV的handler中調用gdb,因而第三個方法又誕生了:
3.段錯誤時啓動調試:

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>

void dump(int signo)
{
        char buf[1024];
        char cmd[1024];
        FILE *fh;

        snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());
        if(!(fh = fopen(buf, "r")))
                exit(0);
        if(!fgets(buf, sizeof(buf), fh))
                exit(0);
        fclose(fh);
        if(buf[strlen(buf) - 1] == '\n')
                buf[strlen(buf) - 1] = '\0';
        snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());
        system(cmd);

        exit(0);
}

        void
dummy_function (void)
{
        unsigned char *ptr = 0x00;
        *ptr = 0x00;
}

        int
main (void)
{
        signal(SIGSEGV, &dump);
        dummy_function ();

        return 0;
}

編譯運行效果以下:

xiaosuo@gentux test $ gcc -g -rdynamic f.c
xiaosuo@gentux test $ ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Attaching to program: /home/xiaosuo/test/a.out, process 9563
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ee4b53 in waitpid () from /lib/libc.so.6
#2  0xb7e925c9 in strtold_l () from /lib/libc.so.6
#3  0x08048830 in dump (signo=11) at f.c:22
#4  <signal handler called>
#5  0x0804884c in dummy_function () at f.c:31
#6  0x08048886 in main () at f.c:38

怎麼樣?是否是依舊很酷?
以上方法都是在系統上有gdb的前提下進行的,若是沒有呢?其實glibc爲咱們提供了此類可以dump棧內容的函數簇,詳見/usr/include/execinfo.h(這些函數都沒有提供man page,難怪咱們找不到),另外你也能夠經過gnu的手冊進行學習。
4.利用backtrace和objdump進行分析:
重寫的代碼以下:

#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

/* A dummy function to make the backtrace more interesting. */
        void
dummy_function (void)
{
        unsigned char *ptr = 0x00;
        *ptr = 0x00;
}

void dump(int signo)
{
        void *array[10];
        size_t size;
        char **strings;
        size_t i;

        size = backtrace (array, 10);
        strings = backtrace_symbols (array, size);

        printf ("Obtained %zd stack frames.\n", size);

        for (i = 0; i < size; i++)
                printf ("%s\n", strings[i]);

        free (strings);

        exit(0);
}

        int
main (void)
{
        signal(SIGSEGV, &dump);
        dummy_function ();

        return 0;
}

編譯運行結果以下:

xiaosuo@gentux test $ gcc -g -rdynamic g.c
xiaosuo@gentux test $ ./a.out
Obtained 5 stack frames.
./a.out(dump+0x19) [0x80486c2]
[0xffffe420]
./a.out(main+0x35) [0x804876f]
/lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866]
./a.out [0x8048601]

此次你可能有些失望,彷佛沒能給出足夠的信息來標示錯誤,不急,先看看能分析出來什麼吧,用objdump反彙編程序,找到地址0x804876f對應的代碼位置:

xiaosuo@gentux test $ objdump -d a.out

 8048765:       e8 02 fe ff ff          call   804856c <signal@plt>
 804876a:       e8 25 ff ff ff          call   8048694 <dummy_function>
 804876f:       b8 00 00 00 00          mov    $0x0,%eax
 8048774:       c9                      leave

咱們仍是找到了在哪一個函數(dummy_function)中出錯的,信息已然不是很完整,不過有總比沒有好的啊!
後記: 本文給出了分析"段錯誤"的幾種方法,不要認爲這是與孔乙己先生的"回"字四種寫法同樣的哦,由於每種方法都有其自身的適用範圍和適用環境,請酌情使用,或遵醫囑。

相關文章
相關標籤/搜索