精华内容
下载资源
问答
  • linux段错误
    千次阅读
    2019-01-01 22:59:36

    (1)Linux环境下段错误的产生原因及调试方法小结
    http://www.cnblogs.com/lidabo/p/5014591.html

    更多相关内容
  • 最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是著名的“段错误”(Segmentation Fault)。借此机会系统...
  • Linux C段错误定位

    2014-06-08 12:33:44
    嵌入式开发中有时候代码量庞大,需要进行错误地点定位,我自己写了一个段错误定位的实例,目前只能将错误定位到调用函数级别,不过相信把发生错误的函数找到了,离找到错误的原因也不远了。
  • Linux段错误Segfault内核层面分析

    千次阅读 2018-11-16 11:42:46
    最近编写Linux用户态程序,会涉及到一些对内存的操作,因此经常会遇到段错误。 segfault at 99ef469b ip 0000000099ef469b sp 00007ffff238e878 error 14 in zero (deleted)[7f6299ef4000+7a2000] 最近老是遇到一...

    最近编写Linux用户态程序,会涉及到一些对内存的操作,因此经常会遇到段错误。

    segfault at 99ef469b ip 0000000099ef469b sp 00007ffff238e878 error 14 in zero (deleted)[7f6299ef4000+7a2000]

    最近老是遇到一个错误码为14的段错误,通过网络查阅资料,发现很多资料都写的是错误码是由三个bit来表示,我还根据这些资料做了笔记如下:

    error number是由三个bit组成的,从高到底分别为bit2 bit1和bit0,所以它的取值范围是0~7。

    bit2: 值为1表示是用户态程序内存访问越界,值为0表示是内核态程序内存访问越界。

    bit1: 值为1表示是写操作导致内存访问越界,值为0表示是读操作导致内存访问越界。

    bit0: 值为1表示没有足够的权限访问非法地址的内容,值为0表示访问的非法地址根本没有对应的页面,也就是无效地址。

    但是我现在遇到了错误码为:14,三个bit根本没办法表示出14,因此我决定去查看到底这样一个段错误是怎样打印出来的。

    我们遇到段错误之后,经常做的就是通过dmesg打印出段错误信息,通过这里我觉得可以在内核源码中进行查找。

    由于最近开发使用的内核版本是linux-3.10,所以我决定先在3.10中找,然后再到linux-4.4.4中进行比对。

    最终找到在内核源码文件:/arch/x86/mm目录下fault.c文件。

    linux-3.10 ——> linux-3.10/arch/x86/mm/fault.c

    linux-4.4.4 ——> linux-4.4.4/arch/x86/mm/fault.c

    在里面找到了,show_signal_msg函数,里面内容如下:

    /*
     * Print out info about fatal segfaults, if the show_unhandled_signals
     * sysctl is set:
     * 如果设置了show_unhandled_signals sysctl,请打印有关致命段错误的信息:
     */
    static inline void
    show_signal_msg(struct pt_regs *regs, unsigned long error_code,
    		unsigned long address, struct task_struct *tsk)
    {
    	if (!unhandled_signal(tsk, SIGSEGV))
    		return;
    
    	if (!printk_ratelimit())
    		return;
    
    	printk("%s%s[%d]: segfault at %lx ip %p sp %p error %lx",
    		task_pid_nr(tsk) > 1 ? KERN_INFO : KERN_EMERG,
    		tsk->comm, task_pid_nr(tsk), address,
    		(void *)regs->ip, (void *)regs->sp, error_code);
    
    	print_vma_addr(KERN_CONT " in ", regs->ip);
    
    	printk(KERN_CONT "\n");
    }

    通过里面的内容基本可以断定dmesg中打印出来的段错误信息就是出自这个函数,但是为了保证绝对的正确性,还是通过更改内核源码,在里面添加一个打印信息来判断是否由这个函数输出。

    通过添加判断打印信息,重新编译内核,最后在两个版本内核中都看到了我们的打印信息:

    linux-3.10:

    linux-4.4.4:

    添加代码的位置有点不多,所以扰乱了报错信息,不过不影响判断。蓝色框中标出的内容就是我添加的打印信息,从中可以确定两个版本内核都是通过show_signal_msg输出段错误信息的。

    错误码是通过一个error_code的参数表示的,继续在fault.c中查找,发现如下内容:

    /*
     * Page fault error code bits:
     *
     *   bit 0 ==	 0: no page found	1: protection fault
     *   bit 1 ==	 0: read access		1: write access
     *   bit 2 ==	 0: kernel-mode access	1: user-mode access
     *   bit 3 ==				1: use of reserved bit detected
     *   bit 4 ==				1: fault was an instruction fetch
     */
    enum x86_pf_error_code {
    
    	PF_PROT		=		1 << 0,
    	PF_WRITE	=		1 << 1,
    	PF_USER		=		1 << 2,
    	PF_RSVD		=		1 << 3,
    	PF_INSTR	=		1 << 4,
    };

    由此其实发现,错误码其实是由5个bit来进行表示的,而且每个bit取值不同的含义都进行了说明,通过这个我们就判断出了到底是发生了什么错误,然后结合

    https://blog.csdn.net/SweeNeil/article/details/83926778

    来进行调试排查即可!!

    欢迎交流讨论~

    展开全文
  • 但是手工“除虫”(debug),往往是效率低下且让人厌烦的,本文将就"段错误"这个内存访问越界的错误谈谈如何快速定位这些"段错误"的语句。 下面将就以下的一个存在段错误的程序介绍几种调试方法:

    我们在用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
                  *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
                  *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>


            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)中出错的,信息已然不是很完整,不过有总比没有好的啊!
    后记:
    本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。
    Note:打印数字是却用%s也会出现段错误。
    我们在用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
                  *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
                  *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>


            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)中出错的,信息已然不是很完整,不过有总比没有好的啊!
    后记:
    本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。
    Note:打印数字是却用%s也会出现段错误。
    展开全文
  • 现在错误码是: segfault at bfbdd69b ip 00000000bfbdd69b sp 00007fff77a5f368 error 14 in zero (deleted)[7f65bfbdd000+7a2000] 这是什么原因造成的呢,看到了错误码的定义但还是不太明白 /* * Page ...
  • LINUX段错误问题

    2022-06-30 11:46:16
    最近经常出现段错误,然后程序崩溃导致游戏掉线无法连接。由于出错程序是源代码生成的,我这里没有源码,报错程序打开都是一堆16进制的数字看不懂。找了各种方法都无法定位到错误的地方。因为没源码所以修改不了。有...
  • [授权发表]Linux 段错误详解

    千次阅读 2015-05-21 23:32:00
    笔者早年写过一篇:《可恶的"Segmentation faults"之初级总结篇》,网络转载甚多。多年下来,关于段错误的讨论依旧很热烈,该问题也还是很常见。所以打算在这里再系统地梳理一下该问题的来龙去脉。

    By Falcon of TinyLab.org
    2015/05/12

    最初发表:泰晓科技 – 聚焦嵌入式 Linux,追本溯源,见微知著!
    原文链接:Linux 段错误详解
    评论说明:为更好地聚合大家的讨论,请到上面原文的评论区回复。


    背景

    笔者早年写过一篇:《可恶的"Segmentation faults"之初级总结篇》,网络转载甚多。多年下来,关于段错误的讨论依旧很热烈,该问题也还是很常见。所以打算在这里再系统地梳理一下该问题的来龙去脉。

    什么是段错误

    下面是来自 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.

    另外,网上还有个基本上对照的中文解释:

    所谓的段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由 gdtr 来保存的,他是一个 48 位的寄存器,其中的 32 位是保存由它指向的 gdt 表,后 13 位保存相应于 gdt 的下标,最后 3 位包括了程序是否在内存中以及程序的在 cpu 中的运行级别,指向的 gdt 是由以 64 位为一个单位的表,在这张表中就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界访问,cpu 就会产生相应的异常保护,于是 segmentation fault 就出现了

    通过上面的解释,段错误应该就是访问了不可访问的内存,这个内存区要么是不存在的,要么是受到系统保护的。

    段错误日志分析

    例子

    一个典型的例子是 scanf 参数使用错误:

    #include <stdio.h>
    
    int main(int argc, char *argv[])
    {
            int i; 
    
            scanf("%d\n", i);
    
            return 0;
    }
    

    文件保存为 segfault-scanf.c。其中 &i 写成了 i

    段错误信息

    $ make segfault-scanf
    $ ./segfault-scanf
    100
    Segmentation fault (core dumped)
    

    段错误分析

    $ catchsegv ./segfault-scanf
    100
    Segmentation fault (core dumped)
    *** Segmentation fault
    Register dump:
    
     RAX: 0000000000000ca0   RBX: 0000000000000040   RCX: 0000000000000010
     RDX: 0000000000000000   RSI: 0000000000000000   RDI: 1999999999999999
     RBP: 00007fffdbdf1010   R8 : 00007fbb45330060   R9 : 0000000000000000
     R10: 0000000000000ca0   R11: 0000000000000000   R12: 0000000000000004
     R13: 0000000000000000   R14: 00007fbb45330640   R15: 000000000000000a
     RSP: 00007fffdbdf0c20
    
     RIP: 00007fbb44fc761a   EFLAGS: 00010212
    
     CS: 0033   FS: 0000   GS: 0000
    
     Trap: 0000000e   Error: 00000006   OldMask: 00000000   CR2: 00000000
    
     FPUCW: 0000037f   FPUSW: 00000000   TAG: 00000000
     RIP: 00000000   RDP: 00000000
    
     ST(0) 0000 0000000000000000   ST(1) 0000 0000000000000000
     ST(2) 0000 0000000000000000   ST(3) 0000 0000000000000000
     ST(4) 0000 0000000000000000   ST(5) 0000 0000000000000000
     ST(6) 0000 0000000000000000   ST(7) 0000 0000000000000000
     mxcsr: 1f80
     XMM0:  00000000000000000000000000000000 XMM1:  00000000000000000000000000000000
     XMM2:  00000000000000000000000000000000 XMM3:  00000000000000000000000000000000
     XMM4:  00000000000000000000000000000000 XMM5:  00000000000000000000000000000000
     XMM6:  00000000000000000000000000000000 XMM7:  00000000000000000000000000000000
     XMM8:  00000000000000000000000000000000 XMM9:  00000000000000000000000000000000
     XMM10: 00000000000000000000000000000000 XMM11: 00000000000000000000000000000000
     XMM12: 00000000000000000000000000000000 XMM13: 00000000000000000000000000000000
     XMM14: 00000000000000000000000000000000 XMM15: 00000000000000000000000000000000
    
    Backtrace:
    /lib/x86_64-linux-gnu/libc.so.6(_IO_vfscanf+0x303a)[0x7fbb44fc761a]
    /lib/x86_64-linux-gnu/libc.so.6(__isoc99_scanf+0x109)[0x7fbb44fce399]
    ??:?(main)[0x400587]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fbb44f91ec5]
    ??:?(_start)[0x400499]
    
    Memory map:
    
    00400000-00401000 r-xp 00000000 08:09 2903814 segfault-scanf
    00600000-00601000 r--p 00000000 08:09 2903814 segfault-scanf
    00601000-00602000 rw-p 00001000 08:09 2903814 segfault-scanf
    01b98000-01bbd000 rw-p 00000000 00:00 0 [heap]
    7fbb44d5a000-7fbb44d70000 r-xp 00000000 08:02 1710807 /lib/x86_64-linux-gnu/libgcc_s.so.1
    7fbb44d70000-7fbb44f6f000 ---p 00016000 08:02 1710807 /lib/x86_64-linux-gnu/libgcc_s.so.1
    7fbb44f6f000-7fbb44f70000 rw-p 00015000 08:02 1710807 /lib/x86_64-linux-gnu/libgcc_s.so.1
    7fbb44f70000-7fbb4512b000 r-xp 00000000 08:02 1731685 /lib/x86_64-linux-gnu/libc-2.19.so
    7fbb4512b000-7fbb4532b000 ---p 001bb000 08:02 1731685 /lib/x86_64-linux-gnu/libc-2.19.so
    7fbb4532b000-7fbb4532f000 r--p 001bb000 08:02 1731685 /lib/x86_64-linux-gnu/libc-2.19.so
    7fbb4532f000-7fbb45331000 rw-p 001bf000 08:02 1731685 /lib/x86_64-linux-gnu/libc-2.19.so
    7fbb45331000-7fbb45336000 rw-p 00000000 00:00 0
    7fbb45336000-7fbb4533a000 r-xp 00000000 08:02 1731696 /lib/x86_64-linux-gnu/libSegFault.so
    7fbb4533a000-7fbb45539000 ---p 00004000 08:02 1731696 /lib/x86_64-linux-gnu/libSegFault.so
    7fbb45539000-7fbb4553a000 r--p 00003000 08:02 1731696 /lib/x86_64-linux-gnu/libSegFault.so
    7fbb4553a000-7fbb4553b000 rw-p 00004000 08:02 1731696 /lib/x86_64-linux-gnu/libSegFault.so
    7fbb4553b000-7fbb4555e000 r-xp 00000000 08:02 1731686 /lib/x86_64-linux-gnu/ld-2.19.so
    7fbb45729000-7fbb4572c000 rw-p 00000000 00:00 0
    7fbb4575a000-7fbb4575d000 rw-p 00000000 00:00 0
    7fbb4575d000-7fbb4575e000 r--p 00022000 08:02 1731686 /lib/x86_64-linux-gnu/ld-2.19.so
    7fbb4575e000-7fbb4575f000 rw-p 00023000 08:02 1731686 /lib/x86_64-linux-gnu/ld-2.19.so
    7fbb4575f000-7fbb45760000 rw-p 00000000 00:00 0
    7fffdbdd2000-7fffdbdf3000 rw-p 00000000 00:00 0
    7fffdbdfe000-7fffdbe00000 r-xp 00000000 00:00 0 [vdso]
    ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
    

    上述日志包含了寄存器、回调以及内存映像信息。其中回调部分的 _IO_vfscanf 即指出了 scanf 的问题。不过咋一看不明显,可以用 gdb 单步跟踪进行确认。

    关于寄存器我们最关心的信息:

     Trap: 0000000e   Error: 00000006
    

    arch/x86/include/asm/traps.harch/x86/kernel/traps.c 找到 SIGSEGV 的类型有:

    /* Interrupts/Exceptions */
    enum {
            ...
            X86_TRAP_OF,            /*  4, Overflow */
            X86_TRAP_BR,            /*  5, Bound Range Exceeded */
            X86_TRAP_TS,            /* 10, Invalid TSS */
            X86_TRAP_GP,            /* 13, General Protection Fault */
            X86_TRAP_PF,            /* 14, Page Fault */
            ...
    }
    

    Trap 为 0xe,即 14,也就是 Page Fault。

    arch/x86/mm/fault.c 则详细解释了错误码(Error):

    /*
     * Page fault error code bits:
     *
     *   bit 0 ==    0: no page found       1: protection fault
     *   bit 1 ==    0: read access         1: write access
     *   bit 2 ==    0: kernel-mode access  1: user-mode access
     *   bit 3 ==                           1: use of reserved bit detected
     *   bit 4 ==                           1: fault was an instruction fetch
     */
    enum x86_pf_error_code {
    
            PF_PROT         =               1 << 0,
            PF_WRITE        =               1 << 1,
            PF_USER         =               1 << 2,
            PF_RSVD         =               1 << 3,
            PF_INSTR        =               1 << 4,
    };
    

    上面的错误码:6,二进制为 110 即:

    • 1: user-mode access
    • 1: write access
    • 0: no page found

    也可以用 在线查看工具,例如,输入错误码 6 即可获得:

    The cause was a user-mode write resulting in no page being found.

    常见段错误举例

    这里列举一下常见的段错误例子。

    scanf 参数:把 &i 写为 i

    int i;
    scanf("%d", i);
    

    分析:i 被定义后,数值是不确定的,而 scanf 把 i 的值当作参数传入 scanf,而 scanf 则会把 i 当成了地址,把用户输入的内容存入该处。而该地址因为随机,可能根本就不存在或者不合法。

    sprintf/printf 参数:%d/%c 写成 %s

    int i = 10;
    printf("%s", i);
    

    分析:打印字串时,实际上是打印某个地址开始的所有字符,而这里把整数作为参数传递过去,这个整数被当成了一个地址,然后 printf 从这个地址开始打印字符,直到某个位置上的值为 \0。如果这个整数代表的地址不存在或者不可访问,自然也是访问了不该访问的内存 —— segmentation fault。

    数组访问越界

    char test[1];
    printf("%c", test[1000000000]);
    

    :也可能报告为 Bus Error,可能存在对未对齐的地址读或写。

    写只读内存

    char *ptr = "test";
    strcpy(ptr, "TEST");
    

    分析:ptr 被定义成了 “test”,是一个只读的内存段,不能直接写入,要写入需要用 malloc 从堆中分配或者定义成一个字符串数组。

    堆栈溢出

    void main()
    {
        main();
    }
    

    分析:上面实际上是一个死循环的递归调用,会造成堆栈溢出。

    pthread_create() 失败后 pthread_join()

    #define THREAD_MAX_NUM
    pthread_t thread[THREAD_MAX_NUM];
    

    分析:用 pthread_create() 创建了各个线程,然后用 pthread_join() 来等待线程的结束。刚开始直接等待,在创建线程都成功时,pthread_join() 能顺利等到各个线程结束,但是一旦创建线程失败,用 pthread_join() 来等待那个本不存在的线程时自然会存在未知内存的情况,从而导致段错误的发生。解决办法是:在创建线程之前,先初始化线程数组,在等待线程结束时,判断线程是否为初始值,如果是的话,说明线程并没有创建成功,所以就不能等拉。

    小结

    综上所有例子,

    • 定义了指针后记得初始化,在使用时记得判断是否为 NULL
    • 在使用数组时记得初始化,使用时要检查数组下标是否越界,数组元素是否存在等
    • 在变量处理时变量的格式控制是否合理等

    其他的就需要根据经验不断积累,更多例子会不断追加到上述列表中。

    另外,也务必掌握一些基本的分析和调试手段,即使在遇到新的这类问题时也知道如何应对。

    分析和调试手段

    分析方法除了最简便的 catchsegv 外,还有诸多办法,它们的应用场景各异。

    catchsegv 原理

    该工具就是用来扑获段错误的,它通过动态加载器(ld-linux.so)的预加载机制(PRELOAD)把一个事先写好的库(/lib/libSegFault.so)加载上,用于捕捉断错误的出错信息。

    gdb 调试

    gdb ./segfault-scanf 
    ...
    Reading symbols from ./segfault-scanf...done.
    (gdb) r
    Starting program: segfault-scanf 
    100
    
    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff7a6b61a in _IO_vfscanf_internal (s=<optimized out>, 
        format=<optimized out>, argptr=argptr@entry=0x7fffffffddc8, 
        errp=errp@entry=0x0) at vfscanf.c:1857
    1857	vfscanf.c: No such file or directory.
    (gdb) bt
    #0  0x00007ffff7a6b61a in _IO_vfscanf_internal (s=<optimized out>, 
        format=<optimized out>, argptr=argptr@entry=0x7fffffffddc8, 
        errp=errp@entry=0x0) at vfscanf.c:1857
    #1  0x00007ffff7a72399 in __isoc99_scanf (format=<optimized out>)
        at isoc99_scanf.c:37
    #2  0x0000000000400580 in main ()
    

    coredump 分析

    $ ulimit -c 1024
    $ gdb segfault-scanf ./core 
    Reading symbols from segfault-scanf...done.
    [New LWP 16913]
    Core was generated by `./segfault-scanf'.
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  0x00007fd2d24ec61a in _IO_vfscanf_internal (s=<optimized out>, 
        format=<optimized out>, argptr=argptr@entry=0x7fff14dfa668, 
        errp=errp@entry=0x0) at vfscanf.c:1857
    1857	vfscanf.c: No such file or directory.
    

    程序内捕获 SIGSEGV 信号并启动 gdb

    #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);
    }
    
    int main(int argc, char *argv[])
    {
            int i; 
    
            signal(SIGSEGV, &dump);
            scanf("%d\n", i);
    
            return 0;
    }
    

    用法如下:

    $ gcc -g -rdynamic -o segfault-scanf segfault-scanf.c
    $ sudo ./segfault-scanf
    100
    (gdb) bt
    #0  0x00007fb743e065cc in __libc_waitpid (pid=16988, 
        stat_loc=stat_loc@entry=0x7fffb51d8fe0, options=options@entry=0)
        at ../sysdeps/unix/sysv/linux/waitpid.c:31
    #1  0x00007fb743d8b1d2 in do_system (line=<optimized out>)
        at ../sysdeps/posix/system.c:148
    #2  0x0000000000400ba1 in dump (signo=11) at segfault-scanf.c:21
    #3  <signal handler called>
    #4  0x00007fb743d9c61a in _IO_vfscanf_internal (s=<optimized out>, 
        format=<optimized out>, argptr=argptr@entry=0x7fffb51da318, 
        errp=errp@entry=0x0) at vfscanf.c:1857
    #5  0x00007fb743da3399 in __isoc99_scanf (format=<optimized out>)
        at isoc99_scanf.c:37
    #6  0x0000000000400bdd in main (argc=1, argv=0x7fffb51da508)
        at segfault-scanf.c:31
    

    程序内捕获 SIGSEGV 信号并调用 backtrace() 获取回调

    #include <stdio.h>
    #include <stdlib.h>
    #include <signal.h>
    #include <string.h>
    
    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(int argc, char *argv[])
    {
            int i; 
    
            signal(SIGSEGV, &dump);
            scanf("%d\n", i);
    
            return 0;
    }
    

    用法如下:

    $ ./segfault-scanf
    100
    Obtained 7 stack frames.
    ./segfault-scanf() [0x40077e]
    /lib/x86_64-linux-gnu/libc.so.6(+0x36c30) [0x7f249fa43c30]
    /lib/x86_64-linux-gnu/libc.so.6(_IO_vfscanf+0x303a) [0x7f249fa6461a]
    /lib/x86_64-linux-gnu/libc.so.6(__isoc99_scanf+0x109) [0x7f249fa6b399]
    ./segfault-scanf-call-backtrace() [0x400837]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f249fa2eec5]
    ./segfault-scanf-call-backtrace() [0x400699]
    

    除此之外,还可以通过 dmesg 查看内核信息并通过 objdump 或者 addr2line 把 IP 地址转化为代码行,不过用法没有 catchsegv 来得简单。dmesg 获取的内核信息由 arch/x86/mm/fault.c: show_signal_msg() 打印。

    总结

    段错误是 Linux 下 C 语言开发常见的 Bug,本文从原理、案例、分析和调试方法等各个方面进行了详细分析,希望有所帮助。

    如果希望了解更多,推荐阅读如下参考资料。

    参考资料

    展开全文
  • 此文档将可能出现的Linux下的段错误产生的原因及调试方法罗列详尽
  • 段错误(核心已转储)-linux

    万次阅读 2019-02-23 10:19:03
    在终端输入:ulimit -a 会发现提示很多 重点关注两个,一个是core file size,还有一个是stack size vi .bashrc 在bashrc文件最后加 ulimit -c unlimited ulimit -s 819200 保存后关闭终端 ... ...
  • linux 吐核段错误

    2020-05-10 12:17:37
    可能原因: 1.数组开太大 2.空指针 (遇到新的原因再更新)
  • Linux上如何得到一个段错误的核心转储 文章目录什么是段错误?步骤1:运行 valgrind如何获得一个核心转储ulimit:设置核心转储的最大尺寸kernel.core_pattern:核心转储保存在哪里kernel.core_pattern 和 Ubuntu...
  • linux调试段错误(吐核)设置

    千次阅读 2019-08-22 15:58:53
    linux编译c/c+程序会出现段错误,单单是出现段错误什么也没留下的话,调试就比较麻烦。 为了解决这个问题,我们可以设置段错误吐核。 这种设置有两种 一种是当前shell有效,另一种是永久有效。 第一种当前shell...
  • core文件是程序在运行过程中出现段错误退出时,用于保存让gdb调试的堆栈错误信息的文件 某些Linux系统下默认是没有设置core文件的,需要我们查看一下; 如果查看到core为0字节的话,就说明系统没有设置,那么我们要在...
  • Linux环境下段错误的产生原因及调试总结文档,亲身经历
  • linux中利用tacktrace信息解决段错误
  • 段错误linux

    2012-09-18 17:00:56
    主要是是描写遇到的段错误,并提供解决方法
  • Linux段错误,核心已转储”

    千次阅读 2019-09-29 08:42:00
    最近一个代码编译之后,运行老是报“段错误,核心已转储”,用gdb的bt命令也无法定位到原因。最后发现是因为一个返回int类型的函数没有写return。windows下面没有return的会自己return,linux下编译警告没有return,...
  • Linux 段错误详解

    千次阅读 2016-04-06 20:59:26
    2什么是段错误 3段错误日志分析 3.1例子 3.2段错误信息 3.3段错误分析 4常见段错误举例 4.1scanf 参数:把 &i 写为 i 4.2sprintf/printf 参数:%d/%c 写成 %s 4.3数组访问越界 4.4写只读内存 4.5
  • Linux C中段错误常见解决办法

    千次阅读 2019-06-12 09:21:11
    通过命令sudo cat /var/log/messages |grep segfault 或者sudo dmesg|grep segfault 来查询段错误的具体信息。 这种信息一般都是由内存访问越界造成的,不管是用户态程序还是内核态程序访问越界都会出core, 并在...
  • linux c段错误处理

    2013-04-17 11:39:49
    linux c段错误处理
  • Linux上跑服务器如果遇到程序崩溃是一件很苦恼的事情, 再碰到重现很难的BUG, 估计只能通过传统的排查方法进行. 在编写本文前, 笔者使用过诸如libunwind等库进行错误时堆栈打印, 但是其本身由于需要引用第三方库, ...
  • linux调试段错误(吐核)问题小结

    千次阅读 2019-03-27 23:18:25
    段错误吐核一般都是和内存有关系,出现这种问题一般都要编译能通过。 我总结了一下几点原因: 1.使用地址变量时没有带取址符; 2.字符串为空时:使用字符串要求不为空时,而使用时忘记赋值。 3.程序中出现中文...
  • [Linux] 什么是 段错误(吐核)?

    万次阅读 多人点赞 2018-12-29 00:56:41
    段错误 我们在Linux环境下编程中,有时执行编译好的文件时会出现段错误(吐核),这是经常出现的一个错误。 它是什么意思呢? 这个错误过程中都有哪些文件? 与VS中IDE直接报错有何不同?我们将通过本篇进行探讨。 ...
  • 简而言之就是访问了错误的内存或者是0地址。 表现/现象 在Eclipse的输出框或者Linux终端调用运行的时候报出xxxxx文件的某一行有一个segment error/fault 这个问题属于比较棘手和麻烦的问题,因为像这个内存报错...
  • 段错误(核心已转储)的问题原因

    千次阅读 2022-02-14 22:43:54
    一个困扰已久的问题,今天终于明白了。 core,核心(线圈),没有半导体之前,使用线圈内存,指代内存。 可执行文件是分段存储的,加载进内存也是分段的,如代码段、数据段、堆、...[Linux] 什么是 段错误(吐核)
  • Linux中快速定位段错误的方法

    千次阅读 2018-03-28 23:39:05
    在做嵌入式Linux开发的时候,程序很容易出现段错误段错误一般是内存操作指针出错或是内存溢出等问题,有的时候系统会有一点错误提示,但有的时候就直接提示个Segmentation fault (core dumped) 。如果程序是单线程...
  • Linux段错误及GDB Coredump调试方法

    千次阅读 2017-07-03 19:16:29
    最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是著名的“段错误”(Segmentation Fault)。借此机会系统...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 387,531
精华内容 155,012
关键字:

linux段错误