• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            面對現(xiàn)實,超越自己
            逆水行舟,不進(jìn)則退
            posts - 269,comments - 32,trackbacks - 0
            Linux下的段錯誤產(chǎn)生的原因及調(diào)試方法

               原文地址:http://www.upsdn.net/html/2006-11/775.html 
               參考地址:http://www.cnblogs.com/khler/archive/2010/09/16/1828349.html 

            簡而言之,產(chǎn)生段錯誤就是訪問了錯誤的內(nèi)存段,一般是你沒有權(quán)限,或者根本就不存在對應(yīng)的物理內(nèi)存,尤其常見的是訪問0地址.

            一般來說,段錯誤就是指訪問的內(nèi)存超出了系統(tǒng)所給這個程序的內(nèi)存空間,通常這個值是由gdtr來保存的,他是一個48位的寄存器,其中的32位是保存由它指向的gdt表,后13位保存相應(yīng)于gdt的下標(biāo),最后3位包括了程序是否在內(nèi)存中以及程序的在cpu中的運行級別,指向的gdt是由以64位為一個單位的表,在這張表中就保存著程序運行的代碼段以及數(shù)據(jù)段的起始地址以及與此相應(yīng)的段限和頁面交換還有程序運行級別還有內(nèi)存粒度等等的信息。一旦一個程序發(fā)生了越界訪問,cpu就會產(chǎn)生相應(yīng)的異常保護(hù),于是segmentation fault就出現(xiàn)了.

            在編程中以下幾類做法容易導(dǎo)致段錯誤,基本是是錯誤地使用指針引起的

            1)訪問系統(tǒng)數(shù)據(jù)區(qū),尤其是往  系統(tǒng)保護(hù)的內(nèi)存地址寫數(shù)據(jù)
               最常見就是給一個指針以0地址
            2)內(nèi)存越界(數(shù)組越界,變量類型不一致等) 訪問到不屬于你的內(nèi)存區(qū)域

            解決方法

            我們在用C/C++語言寫程序的時侯,內(nèi)存管理的絕大部分工作都是需要我們來做的。實際上,內(nèi)存管理是一個比較繁瑣的工作,無論你多高明,經(jīng)驗多豐富,難 免會在此處犯些小錯誤,而通常這些錯誤又是那么的淺顯而易于消除。但是手工“除蟲”(debug),往往是效率低下且讓人厭煩的,本文將就"段錯誤"這個 內(nèi)存訪問越界的錯誤談?wù)勅绾慰焖俣ㄎ贿@些"段錯誤"的語句。
            下面將就以下的一個存在段錯誤的程序介紹幾種調(diào)試方法:
                 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應(yīng)該是很清楚的,因為它嘗試操作地址為0的內(nèi)存區(qū)域,而這個內(nèi)存區(qū)域通常是不可訪問的禁區(qū),當(dāng)然就會出錯了。我們嘗試編譯運行它:
            xiaosuo@gentux test $ ./a.out
            段錯誤
            果然不出所料,它出錯并退出了。
            1.利用gdb逐步查找段錯誤:
            這種方法也是被大眾所熟知并廣泛采用的方法,首先我們需要一個帶有調(diào)試信息的可執(zhí)行程序,所以我們加上“-g -rdynamic"的參數(shù)進(jìn)行編譯,然后用gdb調(diào)試運行這個新編譯的程序,具體步驟如下:
            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)                       
            哦?!好像不用一步步調(diào)試我們就找到了出錯位置d.c文件的第4行,其實就是如此的簡單。
            從這里我們還發(fā)現(xiàn)進(jìn)程是由于收到了SIGSEGV信號而結(jié)束的。通過進(jìn)一步的查閱文檔(man 7 signal),我們知道SIGSEGV默認(rèn)handler的動作是打印”段錯誤"的出錯信息,并產(chǎn)生Core文件,由此我們又產(chǎn)生了方法二。
            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)。不過奇怪了,我的系統(tǒng)上并沒有找到core文件。后來,憶起為了漸少系統(tǒng)上的拉圾文件的數(shù)量(本人有些潔癖,這也是我喜歡Gentoo的原因 之一),禁止了core文件的生成,查看了以下果真如此,將系統(tǒng)的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文件終于產(chǎn)生了,用gdb調(diào)試一下看看吧:
            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系統(tǒng)的此類設(shè)計。
            接著考慮下去,以前用windows系統(tǒng)下的ie的時侯,有時打開某些網(wǎng)頁,會出現(xiàn)“運行時錯誤”,這個時侯如果恰好你的機器上又裝有windows的編譯器的話,他會彈出來一個對話框,問你是否進(jìn)行調(diào)試,如果你選擇是,編譯器將被打開,并進(jìn)入調(diào)試狀態(tài),開始調(diào)試。
            Linux下如何做到這些呢?我的大腦飛速地旋轉(zhuǎn)著,有了,讓它在SIGSEGV的handler中調(diào)用gdb,于是第三個方法又誕生了:
            3.段錯誤時啟動調(diào)試:
            #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
            怎么樣?是不是依舊很酷?
            以上方法都是在系統(tǒng)上有g(shù)db的前提下進(jìn)行的,如果沒有呢?其實glibc為我們提供了此類能夠dump棧內(nèi)容的函數(shù)簇,詳見/usr/include/execinfo.h(這些函數(shù)都沒有提供man page,難怪我們找不到),另外你也可以通過gnu的手冊進(jìn)行學(xué)習(xí)。
            4.利用backtrace和objdump進(jìn)行分析:
            重寫的代碼如下:
            #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;
            }
            編譯運行結(jié)果如下:
            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]
            這次你可能有些失望,似乎沒能給出足夠的信息來標(biāo)示錯誤,不急,先看看能分析出來什么吧,用objdump反匯編程序,找到地址0x804876f對應(yīng)的代碼位置:
            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
            我們還是找到了在哪個函數(shù)(dummy_function)中出錯的,信息已然不是很完整,不過有總比沒有好的啊!
            后記:
            本文給出了分析"段錯誤"的幾種方法,不要認(rèn)為這是與孔乙己先生的"回"字四種寫法一樣的哦,因為每種方法都有其自身的適用范圍和適用環(huán)境,請酌情使用,或遵醫(yī)囑。

            部分資料來源于xiaosuo @ cnblog.cn, 特此致謝

            作者:upsdn整理   更新日期:2006-11-03
            來源:upsdn.net   瀏覽次數(shù): 



            其它調(diào)試辦法

            • 添加日志 

                        在Linux上的使用開源C++日志庫---log4cplus 



            linux下追蹤函數(shù)調(diào)用堆棧

            一般察看函數(shù)運行時堆棧的方法是使用GDB之類的外部調(diào)試器,但是,有些時候為了分析程序的BUG,(主要針對長時間運行程序的分析),在程序出錯時打印出函數(shù)的調(diào)用堆棧是非常有用的。

             在頭文件"execinfo.h"中聲明了三個函數(shù)用于獲取當(dāng)前線程的函數(shù)調(diào)用堆棧

             Function: int backtrace(void **buffer,int size)

             該函數(shù)用與獲取當(dāng)前線程的調(diào)用堆棧,獲取的信息將會被存放在buffer中,它是一個指針列表。參數(shù) size 用來指定buffer中可以保存多少個void* 元素。函數(shù)返回值是實際獲取的指針個數(shù),最大不超過size大小

             在buffer中的指針實際是從堆棧中獲取的返回地址,每一個堆棧框架有一個返回地址

             注意某些編譯器的優(yōu)化選項對獲取正確的調(diào)用堆棧有干擾,另外內(nèi)聯(lián)函數(shù)沒有堆??蚣?刪除框架指針也會使無法正確解析堆棧內(nèi)容

             Function: char ** backtrace_symbols (void *const *buffer, int size)

             backtrace_symbols將從backtrace函數(shù)獲取的信息轉(zhuǎn)化為一個字符串?dāng)?shù)組. 參數(shù)buffer應(yīng)該是從backtrace函數(shù)獲取的數(shù)組指針,size是該數(shù)組中的元素個數(shù)(backtrace的返回值)

             函數(shù)返回值是一個指向字符串?dāng)?shù)組的指針,它的大小同buffer相同.每個字符串包含了一個相對于buffer中對應(yīng)元素的可打印信息.它包括函數(shù)名,函數(shù)的偏移地址,和實際的返回地址

             現(xiàn)在,只有使用ELF二進(jìn)制格式的程序和苦衷才能獲取函數(shù)名稱和偏移地址.在其他系統(tǒng),只有16進(jìn)制的返回地址能被獲取.另外,你可能需要傳遞相應(yīng)的標(biāo)志給鏈接器,以能支持函數(shù)名功能(比如,在使用GNU ld的系統(tǒng)中,你需要傳遞(-rdynamic))

             該函數(shù)的返回值是通過malloc函數(shù)申請的空間,因此調(diào)用這必須使用free函數(shù)來釋放指針.

             注意:如果不能為字符串獲取足夠的空間函數(shù)的返回值將會為NULL

             Function:void backtrace_symbols_fd (void *const *buffer, int size, int fd)

             backtrace_symbols_fd與backtrace_symbols 函數(shù)具有相同的功能,不同的是它不會給調(diào)用者返回字符串?dāng)?shù)組,而是將結(jié)果寫入文件描述符為fd的文件中,每個函數(shù)對應(yīng)一行.它不需要調(diào)用malloc函數(shù),因此適用于有可能調(diào)用該函數(shù)會失敗的情況。

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

            /* Obtain a backtrace and print it to stdout. */ 
            void print_trace (void

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


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

                    print_trace (); 


            int main (void

                    dummy_function (); 
                    
            return 0
            }
            編譯運行的結(jié)果如下: 
            # gcc bt.c -rdynamic -o bt 
            # ./bt 
            Obtained 5 stack frames.
            ./bt(_Z11print_tracev+0x19) [0x804870d]
            ./bt(_Z14dummy_functionv+0xb) [0x8048779]
            ./bt(main+0x16) [0x8048792]
            /lib/libc.so.6(__libc_start_main+0xdc) [0x116e9c]
            ./bt(__gxx_personality_v0+0x31) [0x8048641]


            注: addr2line - convert addresses into file names and line numbers.
            posted on 2013-07-31 12:07 王海光 閱讀(853) 評論(0)  編輯 收藏 引用 所屬分類: Linux
            久久A级毛片免费观看| 无码国内精品久久人妻蜜桃| 热久久国产精品| 精品无码久久久久久国产| 久久亚洲精品无码播放| 久久无码高潮喷水| 99国产精品久久| 亚州日韩精品专区久久久| 亚洲精品无码专区久久久| 久久精品成人免费网站| 久久久久久无码国产精品中文字幕| 欧美久久天天综合香蕉伊| 亚洲国产精品无码久久一区二区 | www.久久精品| 久久电影网| 精品久久人妻av中文字幕| 午夜福利91久久福利| 精品国产乱码久久久久久1区2区 | 亚洲伊人久久大香线蕉综合图片| 久久99中文字幕久久| 亚洲av日韩精品久久久久久a | 无码AV波多野结衣久久| 久久伊人中文无码| 国产ww久久久久久久久久| 久久亚洲AV成人无码国产| 欧美国产成人久久精品| 99久久精品免费看国产免费| 亚洲女久久久噜噜噜熟女| 欧美亚洲国产精品久久高清| 久久伊人五月天论坛| 久久男人中文字幕资源站| 免费观看久久精彩视频| 久久人人爽爽爽人久久久| 国内精品久久久久久久久电影网| 很黄很污的网站久久mimi色| 久久综合九色综合97_久久久| 69久久夜色精品国产69| 91精品国产高清91久久久久久| 久久精品国产亚洲AV大全| 欧美va久久久噜噜噜久久| 久久婷婷五月综合色奶水99啪|