Linux下的C++程序崩溃时打印崩溃信息

原创 2016年05月31日 19:12:52

概述

在某些极端情况下,原本正常执行的程序发生了崩溃。这时候想通过调试是很难发现出错的地方的,所以在崩溃时打印出错点的调用堆栈是十分有必要的。

使用的命令:catchsegv program [args]
例如:我们的程序是test,则可在控制台输入:catchsegv ./test
如果使用gcc/g++编译test时添加了-g选项(即在可执行程序中加入调试信息),则可以输出崩溃的代码行数。

测试

有如下C++代码(test.cpp):

int main()
{
    int* nInt = 0;
    *nInt = 0; // crash
    return 0;
}

使用g++ test.cpp -o test -g编译此段C++代码,生成test可执行程序。在控制台执行catchsegv ./test,则有如下输出(注意Backtrace:下的):

Segmentation fault (core dumped)
*** Segmentation fault
Register dump:

 RAX: 0000000000000000   RBX: 0000000000000000   RCX: 0000000000000000
 RDX: 00007fff296866f8   RSI: 00007fff296866e8   RDI: 0000000000000001
 RBP: 00007fff29686600   R8 : 00007f0072412e80   R9 : 00007f007262d700
 R10: 00007fff29686490   R11: 00007f0072070e50   R12: 0000000000400400
 R13: 00007fff296866e0   R14: 0000000000000000   R15: 0000000000000000
 RSP: 00007fff29686600

 RIP: 00000000004004fd   EFLAGS: 00010246

 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:
/home/jackripper/Desktop/Test.cpp:7(main)[0x4004fd]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f0072070f45]
??:?(_start)[0x400429]

Memory map:

00400000-00401000 r-xp 00000000 08:01 4723165 /home/jackripper/Desktop/Test
00600000-00601000 r--p 00000000 08:01 4723165 /home/jackripper/Desktop/Test
00601000-00602000 rw-p 00001000 08:01 4723165 /home/jackripper/Desktop/Test
01ab6000-01adb000 rw-p 00000000 00:00 0 [heap]
7f0071e39000-7f0071e4f000 r-xp 00000000 08:01 1445862 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f0071e4f000-7f007204e000 ---p 00016000 08:01 1445862 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f007204e000-7f007204f000 rw-p 00015000 08:01 1445862 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f007204f000-7f007220d000 r-xp 00000000 08:01 1443885 /lib/x86_64-linux-gnu/libc-2.19.so
7f007220d000-7f007240d000 ---p 001be000 08:01 1443885 /lib/x86_64-linux-gnu/libc-2.19.so
7f007240d000-7f0072411000 r--p 001be000 08:01 1443885 /lib/x86_64-linux-gnu/libc-2.19.so
7f0072411000-7f0072413000 rw-p 001c2000 08:01 1443885 /lib/x86_64-linux-gnu/libc-2.19.so
7f0072413000-7f0072418000 rw-p 00000000 00:00 0
7f0072418000-7f007241c000 r-xp 00000000 08:01 1443877 /lib/x86_64-linux-gnu/libSegFault.so
7f007241c000-7f007261b000 ---p 00004000 08:01 1443877 /lib/x86_64-linux-gnu/libSegFault.so
7f007261b000-7f007261c000 r--p 00003000 08:01 1443877 /lib/x86_64-linux-gnu/libSegFault.so
7f007261c000-7f007261d000 rw-p 00004000 08:01 1443877 /lib/x86_64-linux-gnu/libSegFault.so
7f007261d000-7f0072640000 r-xp 00000000 08:01 1443901 /lib/x86_64-linux-gnu/ld-2.19.so
7f0072818000-7f007281b000 rw-p 00000000 00:00 0
7f007283d000-7f007283f000 rw-p 00000000 00:00 0
7f007283f000-7f0072840000 r--p 00022000 08:01 1443901 /lib/x86_64-linux-gnu/ld-2.19.so
7f0072840000-7f0072841000 rw-p 00023000 08:01 1443901 /lib/x86_64-linux-gnu/ld-2.19.so
7f0072841000-7f0072842000 rw-p 00000000 00:00 0
7fff29668000-7fff29689000 rw-p 00000000 00:00 0 [stack]
7fff29797000-7fff29799000 r--p 00000000 00:00 0 [vvar]
7fff29799000-7fff2979b000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

linux下程序被Killed

服务器上跑的一个程序,发现报了Killed

linux下程序崩溃后记录调用堆栈.以便查找问题

在linux下程序崩溃后,一般都会有coredump,但是这个coredump有时候会被截断(尽管已经设置了ulimit -c unlimited也会),导致没法用gdb查看问题所在。 只好想办法在...

分析两种Dump(崩溃日志)文件生成的方法及比较

本文分析和讲解了两种截取dump的方法。一种是使用SetUnhandledExceptionFilter方法设置回调。一种是通过Hook函数UnhandledExceptionFilter实现。后一种...

C++ 程序路在Linux上Crash时生成Carsh报告(Core Dump)

C++ 程序路在Linux上Crash时生成Carsh报告(Core Dump) 包含如下头文件 #include #include 在主函数中添加如下代码段: #i...
  • ghlfllz
  • ghlfllz
  • 2012年05月13日 17:37
  • 4014

在linux下利用程序崩溃后的core文件分析bug

浅析Linux下core文件 当我们的程序崩溃时,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方。最常出 现的,几乎所有C程序员都出现过的错误就是“段错误”了。...
  • Andeewu
  • Andeewu
  • 2014年08月20日 21:44
  • 1310

Linux程序崩溃调试手段--core使用(续)

core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core dump. (linux中如果内存越界会收到SIG...
  • lisayh
  • lisayh
  • 2017年07月05日 13:34
  • 264

内核崩溃的日志

. Linux Kernel Panic的产生的原因      panic是英文中是惊慌的意思,Linux Kernel panic正如其名,linux kernel不知道如何走了,它会尽可能把它此...

linux内核崩溃问题排查过程总结

1.概述 某年某月某日某项目的线上分布式文件系统服务器多台linux系统kernel崩溃,严重影响了某项目对外提供服务的能力,在公司造成了不小影响。通过排查线上问题基本确定了是由于linux内核...

LINUX查看系统日志

cat tail -f 日 志 文 件 说    明 /var/log/message 系统启动后的信息和错误日志,是Red Hat Linux中最常用的日志之一 /var/log/sec...

Linux下进程崩溃时定位源代码位置

在Linux系统下,进程可能由于各种原因崩溃,此时我们要找到出问题的源代码在某一个文件的具体行号,这样调试起来就会方便,高效很多。下面是解决问题的思路和步骤以及自己的一些想法   解决该问题的...
  • twtydgo
  • twtydgo
  • 2016年06月03日 14:01
  • 1262
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Linux下的C++程序崩溃时打印崩溃信息
举报原因:
原因补充:

(最多只允许输入30个字)