Chinaunix首页 | 论坛 | 博客
  • 博客访问: 103647259
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类: LINUX

2008-04-23 09:12:01

作者: Mwany  出自:
Linux下编程(尤其是服务端程序)若由于内存越界或其他原因产生“非法操作”,会导致程序悄无声息地死去,初学者往往不知道程序死掉的原因。本人也曾饱受程序死不瞑目之苦。其实“非法操作”在绝大多数时候是因为“段错误”,即 SIGSEGV。而找到SIGSEGV信号抛出的位置,也就找到了程序死掉的原因。

下面列出一些捕获SIGSEGV的方法。

假设程序名为 myprg,其进程ID(pid)为 2032。

方法一:
# ./myprg // 运行程序
# ps -ef | grep myprg // 找出 myprg 的 pid
# gdb myprg 2032 > debug.log // 让 gdb 接管 myprg 的运行
# (gdb) continue

此方法利用gdb调试器捕获SIGSEGV。上例中,将gdb输出信息存入debug.log,关闭终端,gdb并不退出,继续运行直到 myprg 出错退出。gdb将捕获到出错点。

方法二:
# ./myprg // 运行程序
# Segment fault (core dumped) // 程序死掉了,系统输出 "Segment fault"
# gdb myprg core // 用 gdb 分析 core 文件

此方法利用core文件,进行事后分析。但前提是保证系统会生成core文件。

如何知道系统会不会生成core文件?可输入命令:

# ulimit -a

查看当前core文件大小的限制,若为0,则需将它改为unlimited。

# ulimit -S -c unlimited

或修改 /etc/profile,找到 unlimit -S -c 0,将0改为unlimited,重启系统。

另外,如果程序安装了 SIGSEGV 异常处理函数,那么 gdb myprg core 时显示的并不是真实的出错位置,要想看到真实的出错点,必须暂时去掉异常处理函数。
阅读(618) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~