Ubuntu Qt 使用gdb+core dump定位软件崩溃问题/gdb结合coredump定位崩溃进程

目录

1. 背景

1.1 什么是core dump?

2.使用方法

2.1 设置ubuntu 系统生产core文件

2.1.1 core 文件生成

2.2 Qt 生成调试信息

2.3 gdb调试core文件
1. 背景

日常软件开发调试过程中,会遇到软件运行过程中,不知不觉就死掉了,通过日志无法确定异常的原因.此时就需要通过工具来定位软件在源代码层崩溃在什么地方.gdb+core dump的方式就可以方便于我们定位异常问题位置,进而分析问题的原因.
1.1 什么是core dump?

core dump 叫做核心转储,它是进程运行过程中突然崩溃那一刻的内存快照.操作系统在程序发生异常并且异常在进程内部又没有被捕获的情况下，会把进程此刻内存、寄存器状态、运行堆栈等信息转储保存在一个core文件里.

该文件也是二进制文件，可以使用gdb、elfdump、objdump或者windows下的windebug、solaris下的mdb进行打开分析里面的具体内容。
2.使用方法
2.1 设置ubuntu 系统生产core文件

如果系统没有设置ulimit值大小(默认为0),则系统不会产生对应进程的core文件.

查看core 文件大小

ulimit -a

2.1.1 core 文件生成

core文件一般生成较大,尽量不要做大小限制.

    当前终端有效:在当前终端输入命令:

ulimit -c unlimited   //不限制文件大小

    当前用户有效:在环境变量中添加命令

    $ vim .bashrc
     
    //在文件底部添加:
    ulimit -c unlimited
     
    //保存后,环境变量生效
    $ source .bashrc

通过设置/proc/sys/kernel/core_pattern格式来保存core文件生产位置和文件名

    %%：相当于%
    %p：相当于<pid>
    %u：相当于<uid>
    %g：相当于<gid>
    %s：相当于导致dump的信号的数字
    %t：相当于dump的时间
    %e：相当于执行文件的名称
    %h：相当于hostname

配置文件内容: core-%e-%p-%t

2.2 Qt 生成调试信息

编译时带上-g选项

    QMAKE_CC += -g
    QMAKE_CXX += -g
    QMAKE_LINK += -g

运行程序所产生的core文件指定的目录不能放在windows和linux共享目录下,否则生成的core文件大小为0字节.
2.3 gdb调试core文件

    gdb加载软件

gdb xxx

    进入gdb后,输入命令:

core-file core-xxx

执行效果大致为:

可看到段错误在widget.cpp  Line 31 处.
附：

此方法只能定位崩溃进程，不能检查内存泄露。

 

Linux环境下经常遇到某个进程挂掉而找不到原因，我们可以通过生成core file文件加上gdb来定位。

 

如何产生core file?

我们可以使用ulimit这条命令对core file文件的大小进行设定。

一般默认情况下，core file的大小被设置为了0，这样系统就不dump出core file了。

这时用如下命令进行设置：
ulimit -c unlimited
这样便把core file的大小设置为了无限大，同时也可以使用数字来替代unlimited，对core file的上限值做更精确的设定。

 

生成的core file在哪里?

core file生成的地方是在/proc/sys/kernel/core_pattern文件定义的。

改动到生成到自己定义的目录的方法是：
echo "pattern" > /proc/sys/kernel/core_pattern
并且只有超级用户可以修改这两个文件。

"pattern"类似我们C语言打印字符串的格式，相关标识如下：

%%: 相当于%
%p: 相当于<pid>
%u: 相当于<uid>
%g: 相当于<gid>
%s: 相当于导致dump的信号的数字
%t: 相当于dump的时间
%h: 相当于hostname
%e: 相当于执行文件的名称

这时用如下命令设置生成的core file到系统/tmp目录下，并记录pid以及执行文件名

echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern

 

测试如下代码

 

1. #include <stdio.h>

2.  

3. int func(int *p)

4. {

5. *p = 0;

6. }

7.  

8. int main()

9. {

10. func(NULL);

11. return 0;

12. }

 

生成可执行文件并运行

gcc -o main a.c

root@ubuntu:~# ./main
Segmentation fault (core dumped) 

<-----这里出现段错误并生成core文件了。

在/tmp目录下发现文件core-main-10815 

 

如何查看进程挂在哪里了?

我们可以用

gdb main /tmp/core-main-10815 

查看信息，发现能定位到函数了

Program terminated with signal 11, Segmentation fault.
#0  0x080483ba in func ()

 

如何定位到行?

在编译的时候开启-g调试开关就可以了

gcc -o main -g a.c

gdb main /tmp/core-main-10815 

最终看到的结果如下，好棒。

Program terminated with signal 11, Segmentation fault.
#0  0x080483ba in func (p=0x0) at a.c:5
5          *p = 0;

 

总结一下，需要定位进程挂在哪一行我们只需要4个操作，

ulimit -c unlimited

echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern

gcc -o main -g a.c

gdb main /tmp/core-main-10815 

就可以啦。

 

补充说明：

相关常用gdb命令

1,(gdb) backtrace /* 查看当前线程函数栈回溯 */

以上面的例子为例

Program terminated with signal 11, Segmentation fault.

#0  0x080483ba in func (p=0x0) at main.c:5

5*p = 0;

(gdb) backtrace

#0  0x080483ba in func (p=0x0) at main.c:5

#1  0x080483d4 in main () at main.c:10

如果是多线程环境下(gdb) thread apply all backtrace /* 显示所有线程栈回溯 */

 

2,(gdb) print [var] /* 查看变量值 */

(gdb) print p

$1 = (int *) 0x0

(gdb) print &p

$2 = (int **) 0xbf96d4d4

 

3,(gdb) x/FMT [Address] /* 根据格式查看地址指向的值 */

其中

FMT is a repeat count followed by a format letter and a size letter.

Format letters are o(octal), x(hex), d(decimal), u(unsigned decimal),

  t(binary), f(float), a(address), i(instruction), c(char) and s(string).

Size letters are b(byte), h(halfword), w(word), g(giant, 8 bytes).

The specified number of objects of the specified size are printed

according to the format.

 

(gdb) x/d 0xbf96d4d4

0xbf96d4d4:0

(gdb) x/c 0xbf96d4d4

0xbf96d4d4:0 '\000'

 

另外能导致产生core file文件的信号有以下10种

SIGQUIT：终端退出符

SIGILL：非法硬件指令

SIGTRAP：平台相关的硬件错误，现在多用在实现调试时的断点

SIGBUS：与平台相关的硬件错误，一般是内存错误

SIGABRT：调用abort函数时产生此信号，进程异常终止

SIGFPE：算术异常

SIGSEGV：segment violation，无效内存引用

SIGXCPU：超过了cpu使用资源限制（setrlimit）

SIGXFSZ：超过了文件长度限制（setrlimit）

SIGSYS：无效的系统调用