gdb结合coredump定位崩溃进程

转载: http://lazycat.is-programmer.com/posts/31925.html

更多:

http://blog.chinaunix.net/uid-22816738-id-4074928.html

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

测试如下代码

#include <stdio.h>

int func(int *p)
{
        *p = 0;
}

int main()
{
        func(NULL);
        return 0;
}

生成可执行文件并运行

gcc -o main a.c

[email protected]:~# ./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:无效的系统调用

时间: 2024-10-12 08:10:07

gdb结合coredump定位崩溃进程的相关文章

[转]gdb结合coredump定位崩溃进程

[转]gdb结合coredump定位崩溃进程 http://blog.sina.com.cn/s/blog_54f82cc201013tk4.html Linux环境下经常遇到某个进程挂掉而找不到原因,我们可以通过生成core file文件加上gdb来定位. 如何产生core file? 我们可以使用ulimit这条命令对core file文件的大小进行设定. 一般默认情况下,core file的大小被设置为了0,这样系统就不dump出core file了. 这时用如下命令进行设置: ulimi

转载:gdb结合coredump定位崩溃进程

Linux环境下经常遇到某个进程挂掉而找不到原因,我们可以通过生成core file文件加上gdb来定位. 如何产生core file? 我们可以使用ulimit这条命令对core file文件的大小进行设定. 一般默认情况下,core file的大小被设置为了0,这样系统就不dump出core file了. 这时用如下命令进行设置:ulimit -c unlimited这样便把core file的大小设置为了无限大,同时也可以使用数字来替代unlimited,对core file的上限值做更精

[Debug]用gdb分析coredump文件

1,系统默认是不产生coredump文件的,需要用以下命令使系统产生coredump文件 查看core文件的限制,此时为0,即不成生core文件 ulimit -c 0 打开core文件的限制,不限制core文件的大小,使程序可以产生core文件 ulimit -c unlimited ulimit -c unlimited 2,以下是内存访问错误示例 [cpp] view plaincopy 1 #include<stdio.h> 2 int main() 3 { 4      char* 

使用GDB生成coredump文件【转载】

本文转载自: http://blog.csdn.net/sky_qing/article/details/8548989 如果在测试过程中遇到某个进程的CPU利用率过高或者卡死而需要去调试该进程时,可以利用gdb命令生成coredump文件,然后再去调试coredump文件来定位问题. 那么如何使用gdb生成coredump文件呢?其实步骤很简单: 1. 安装好gdb,然后使用命令 'gdb'.(假设需要调试的进程号为 21509) 2. 使用 ‘attach 21590’命令将gdb附加到进程

gdb调试coredump文件

linux上程序崩溃起来挺烦人,不过linux 比较好的是有gdb. 1.生成coredump文件 echo "ulimit -c unlimited" >> /etc/profile 然后记得敲入命令 source /etc/profile 然后敲入命令: ulimit –c 效果如下: 确认能否生成coredump文件,使用如下命令(使用时注意,我在测的时候会直接退出当前用户) kill -s SIGSEGV $$ 然后回到执行上述命令的路径下即可看到coredump文

gdb调试正在运行的进程

[转自] http://hi.baidu.com/brady_home/blog/item/6b92aa8ffdfee2e6f01f369b.html gdb调试正在运行的进程 2009年04月18日 星期六 下午 08:21 有时会遇到一种很特殊的调试需求,对当前正在运行的其它进程进行调试(正是我今天遇到的情形).这种情况有可能发生在那些无法直接在调试器中运行的进程身上,例如有的进程 只能在系统启动时运行.另外如果需要对进程产生的子进程进行调试的话,也只能采用这种方式.GDB可以对正在执行的程

Xcode7的发布后的crash跟踪,轻松定位崩溃代码 Address Sanitizer: 妈妈再也不用担心 EXC_BAD_ACCESS

Xcode7中苹果为我们增加了两个重要的debug相关功能.了解之后觉得非常实用,介绍给大家. 1.Address Sanitizer: 妈妈再也不用担心 EXC_BAD_ACCESS? EXC_BAD_ACCESS一直是很多开发者的噩梦,因为这个错误很不直观,出现后往往要花很长时间才能定位到错误.苹果这次带来了革命性的提升. 在项目的Scheme中Diagnostics下,选中enable address sanitizer(注意选中后Xcode会重新编译整个项目). 这样设置后,如果再出现类

GDB与coredump错误类文件的解析

GDB与coredump错误类文件的解析 GDB是Linux与UNIX系统下的一款程序调试工具,下面来介绍GDB的用法: 请先看这个程序: 这是我们作为实验的一个小程序,共10行输出4 进行编译如果要用GDB调试必须要加-g参数 这是编译好的文件的正常运行 开始调试这个程序 gdb 加文件名 现在介绍第一个参数l(list)就是如图这样显示程序的内容, l后还可以加数字,就是打印这个行数上下共10行. start程序开始单步调试,自动执行第一步. 参数b 设置断点就是程序函数到这一步暂停等待下一

linux性能异常定位之进程级别

[前言] 本文和大家分享:linux系统下常见得性能异常,怎样定位到进程级别.说简单点,就是:linux性能出问题了,我们需要确定哪些进程影响了linux的性能. 本文主要涉及的linux的常见的性能维度:cpu,内存,io,网络 [涉及工具] top:综合,偏cpu,内存 dstat:综合.磁盘 iostat:磁盘io,全局 iotop:磁盘io,精确到进程,(类似工具还有pidstat) iftop:网络.实时刷新(类似工具还有nload,ifstat) nethogs:进程级别的流量 ss