Linux下C/C++措施调试
当前位置：以往代写 > C/C++ 教程 >Linux下C/C++措施调试

Linux下C/C++措施调试

2019-06-13

Linux下C/C++措施调试

Linux下C/C++措施调试

副标题#e#

Linux下的段错误发生的原因及调试要领

原文地点：http://www.upsdn.net/html/2006-11/775.html

参考地点：http://www.cnblogs.com/khler/archive/2010/09/16/1828349.html

简而言之,发生段错误就是会见了错误的内存段，一般是你没有权限，可能基础就不存在对应的物理内存,尤其常见的是会见0地点.

一般来说,段错误就是指会见的内存超出了系统所给这个措施的内存空间，凡是这个值是由gdtr来生存的，他是一个48位的寄存器，个中的32位是生存由它指向的gdt表，后13位生存相应于gdt的下标，最后3位包罗了措施是否在内存中以及措施的在cpu中的运行级别,指向的gdt是由以64位为一个单元的表，在这张表中就生存着措施运行的代码段以及数据段的起始地点以及与此相应的段限和页面互换尚有措施运行级别尚有内存粒度等等的信息。一旦一个措施产生了越界会见，cpu就会发生相应的异常掩护，于是segmentation fault就呈现了.

在编程中以下几类做法容易导致段错误,根基是是错误地利用指针引起的

1)会见系统数据区，尤其是往  系统掩护的内存地点写数据

最常见就是给一个指针以0地点

2)内存越界(数组越界，变量范例纷歧致等) 会见到不属于你的内存区域

办理要领

我们在用C/C++语言写措施的时侯，内存打点的绝大部门事情都是需要我们来做的。实际上，内存打点是一个较量繁琐的事情，无论你多高超，履历多富厚，难 免会在此处犯些小错误，而凡是这些错误又是那么的浅显而易于消除。可是手工“除虫”（debug），往往是效率低下且让人厌烦的，本文迁就"段错误"这个 内存会见越界的错误谈谈如何快速定位这些"段错误"的语句。

下面迁就以下的一个存在段错误的措施先容几种调试要领：

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

作为一个纯熟的C/C++措施员，以上代码的bug应该是很清楚的，因为它实验操纵地点为0的内存区域，而这个内存区域凡是是不行会见的禁区，虽然就会堕落了。我们实验编译运行它:

[email protected] test $ ./a.out

段错误

公然不出所料，它堕落并退出了。

1.操作gdb慢慢查找段错误:

这种要领也是被公共所熟知并遍及回收的要领，首先我们需要一个带有调试信息的可执行措施，所以我们加上“-g -rdynamic"的参数举办编译，然后用gdb调试运行这个新编译的措施,详细步调如下:

[email protected] test $ gcc -g -rdynamic d.c

[email protected] 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文件，由此我们又发生了要领二。


#p#副标题#e#

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巨细，再试:

[email protected] test $ ulimit -c

0

[email protected] test $ ulimit -c 1000

[email protected] test $ ulimit -c

1000

[email protected] test $ ./a.out

段错误 (core dumped)

[email protected] test $ ls

a.out  core  d.c  f.c  g.c  pango.c  test_iconv.c  test_regex.c

core文件终于发生了，用gdb调试一下看看吧:

[email protected] 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系统的此类设计。
#p#分页标题#e#

接着思量下去，以前用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;
}

#p#副标题#e#

编译运行结果如下:

[email protected] test $ gcc -g -rdynamic f.c

[email protected] 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;
}

#p#副标题#e#

编译运行功效如下：

[email protected] test $ gcc -g -rdynamic g.c

[email protected] 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对应的代码位置:

[email protected] test $ objdump -d a.out

8048765:       e8 02 fe ff ff          call   804856c <[email protected]>

804876a:       e8 25 ff ff ff          call   8048694 <dummy_function>

804876f:       b8 00 00 00 00          mov    $0x0,%eax

8048774:       c9                      leave

我们照旧找到了在哪个函数(dummy_function)中堕落的,信息已然不是很完整,不外有总比没有好的啊!

跋文:
#p#分页标题#e#

本文给出了阐明"段错误"的几种要领,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种要领都有其自身的合用范畴和合用情况,请酌情利用,或遵医嘱。

部门资料来历于xiaosuo @ cnblog.cn, 特此叩谢

作者:upsdn整理   更新日期:2006-11-03

来历:upsdn.net   欣赏次数:

其它调试步伐

添加日志

在Linux上的利用开源C++日志库—log4cplus

linux下追踪函数挪用仓库

一般察看函数运行时仓库的要领是利用GDB之类的外部调试器,可是,有些时候为了阐明措施的BUG,(主要针对长时间运行措施的阐明),在措施堕落时打印出函数的挪用仓库长短常有用的。

在头文件"execinfo.h"中声明白三个函数用于获取当前线程的函数挪用仓库

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

该函数用与获取当前线程的挪用仓库,获取的信息将会被存放在buffer中,它是一个指针列表。参数 size 用来指定buffer中可以生存几多个void* 元素。函数返回值是实际获取的指针个数,最大不高出size巨细

在buffer中的指针实际是从仓库中获取的返回地点,每一个仓库框架有一个返回地点

留意某些编译器的优化选项对获取正确的挪用仓库有滋扰,别的内联函数没有仓库框架;删除框架指针也会使无法正确理会仓库内容

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

backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组. 参数buffer应该是从backtrace函数获取的数组指针,size是该数组中的元素个数(backtrace的返回值)

函数返回值是一个指向字符串数组的指针,它的巨细同buffer沟通.每个字符串包括了一个相对付buffer中对应元素的可打印信息.它包罗函数名，函数的偏移地点,和实际的返回地点

此刻,只有利用ELF二进制名目标措施和心事才气获取函数名称和偏移地点.在其他系统,只有16进制的返回地点能被获取.别的,你大概需要通报相应的符号给链接器,以能支持函数名成果(好比,在利用GNU ld的系统中,你需要通报(-rdynamic))

该函数的返回值是通过malloc函数申请的空间,因此挪用这必需利用free函数来释放指针.

#p#副标题#e#

留意:假如不能为字符串获取足够的空间函数的返回值将会为NULL

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

backtrace_symbols_fd与backtrace_symbols 函数具有沟通的成果,差异的是它不会给挪用者返回字符串数组,而是将功效写入文件描写符为fd的文件中,每个函数对应一行.它不需要挪用malloc函数,因此合用于有大概挪用该函数会失败的环境。

#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; 
}

编译运行的功效如下：

# 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.

    关键字：

在线提交作业