段錯誤bug的調試

我們在用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

xiaosuo@gentux test $ ulimit -c 1000

1000

段錯誤 (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

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

哇，好曆害，還是一步就定位到了錯誤所在地，佩服一下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))

        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

Attaching to program: /home/xiaosuo/test/a.out, process 9563

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

怎麼樣？是不是依舊很酷？

4.利用backtrace和objdump進行分析: 

重寫的代碼如下:

#include <execinfo.h>

/* A dummy function to make the backtrace more interesting. */

        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);

編譯運作結果如下：

xiaosuo@gentux test $ gcc -g -rdynamic g.c

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)中出錯的,資訊已然不是很完整,不過有總比沒有好的啊!

後記: 

本文給出了分析"段錯誤"的幾種方法,不要認為這是與孔乙己先生的"回"字四種寫法一樣的哦,因為每種方法都有其自身的适用範圍和适用環境,請酌情使用,或遵醫囑。

本文轉自http://blog.chinaunix.net/space.php?uid=317451&do=blog&cuid=173718