内存异常经常导致程序出现莫名其妙的错误，往往很难查证，本文介绍在linux下的各种常见内存异常的查证工具和方法。
创新互联-专业网站定制、快速模板网站建设、高性价比芷江网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式芷江网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖芷江地区。费用合理售后完善，十载实体公司更值得信赖。
1 访问空指针/未初始化指针/重复释放内存
对于像访问空指针、未初始化指针（非法地址），重复释放内存等内存异常，linux默认会抛异常。
比如下面代码有空指针访问，编译运行后会coredump
int main()
{
int *p=0;
*p=6;
return 0;
}对于此类问题，我们只要在gcc编译程序时加入-g选项，同时在运行时能够生成coredump文件，利用gdb就可以定位到具体的问题代码行。
1.1 开启coredump
**ulimit -c unlimited** //unlimited表示不限制coredump文件大小，也可指定一个具体值来限制文件最大长度。
1.2 定制core文件名
默认的coredump文件名为core，如果想自己定制core文件名，可以运行如下命令：
**echo "./core-%e-%p-%t" > /proc/sys/kernel/core_pattern**
可以在core_pattern模板中使用变量还很多，见下面的列表：
%% 单个%字符
%p 所dump进程的进程ID
%u 所dump进程的实际用户ID
%g 所dump进程的实际组ID
%s 导致本次core dump的信号
%t core dump的时间 (由1970年1月1日计起的秒数)
%h 主机名
%e 程序文件名
1.3 使用gdb定位代码行
通过gdb即可定位出错代码行
root@ubuntu:/home/zte/test# gcc null.cc -g
root@ubuntu:/home/zte/test# ./a.out
Segmentation fault (core dumped)
root@ubuntu:/home/zte/test# gdb a.out core
.......
Core was generated by `./null'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000004004fd in main () at null.cc:4
4 *p=6;
2、函数栈溢出
局部变量的写越界可能会破坏函数栈导致程序出现各种异常行为，但是OS默认不会在越界的第一现场coredump，因此导致问题查证非常困难。
幸运的是我们可以通过gcc的编译选项-fstack-protector 和 -fstack-protector-all在函数栈被破坏的函数返回时抛异常，从而可以很方便地定位问题所在函数。
代码示例
int main()
{
int a=5;
int *p=&a;
p[3]=6;
return 0;
}上面代码会破坏函数栈，如果我们用gcc直接编译运行，不会抛异常。但是加了编译参数-fstack-protector 和 -fstack-protector-all后，再运行就会抛异常。下面是具体命令执行结果。
root@ubuntu:/home/zte/test# gcc t.c
root@ubuntu:/home/zte/test# ./a.out
root@ubuntu:/home/zte/test# gcc t.c -fstack-protector -fstack-protector-all -g
root@ubuntu:/home/zte/test# ./a.out
*** stack smashing detected ***: ./a.out terminated
Aborted (core dumped)
```
可以进一步用gdb的bt命令定位出问题的函数。
```
root@ubuntu:/home/zte/test# gdb a.out core
。。。。。。。。
Core was generated by `./a.out'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f6bcfab5c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f6bcfab5c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f6bcfab9028 in __GI_abort () at abort.c:89
#2 0x00007f6bcfaf22a4 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7f6bcfc01d70 "*** %s ***: %s terminated\n")
at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007f6bcfb8d83c in __GI___fortify_fail (msg=, msg@entry=0x7f6bcfc01d58 "stack smashing detected")
at fortify_fail.c:38
#4 0x00007f6bcfb8d7e0 in __stack_chk_fail () at stack_chk_fail.c:28
#5 0x00000000004005aa in main () at t.c:7
(gdb) q
3 越界读写动态分配内存/读写已释放动态分配内存
动态分配内存读写越界、读写已释放动态分配内存系统往往不会抛异常，我们可以使用electric-fence来使得读写越界内存/已释放内存后立刻抛异常，加速问题定位。
3.1 安装Electric fence
sudo apt-get install electric-fence
3.2 使用Electric fence
下面是越界写代码
#include
int main()
{
int *p = (int*)malloc(sizeof(int));
p[1] = 6;
return 0;
}
如果使用gcc直接编译运行，不会抛异常。
我们可以加上参数 -lefence -g编译后运行，就会抛异常。通过gdb的bt打印即可定位到问题代码行。
root@ubuntu:/home/zte/test# gcc malloc_read_free.cc -lefence -g
root@ubuntu:/home/zte/test# ./a.out
Electric Fence 2.2 Copyright (C) 1987-1999 Bruce Perens
Segmentation fault (core dumped)autogen.sh
4 内存泄漏
C/C++程序经常被内存泄漏问题困扰，本文介绍使用gperftools来快速定位内存泄漏问题。
4.1 安装gperftools工具
4.1.1 安装automake
sudo apt-get install automake
4.1.2 编译安装libunwind
从https://github.com/libunwind/libunwind/releases下载最新版本的libunwind源码包
解压到/usr/local/src目录
cd 解压源码目录
./autogen.sh
./configure
make -j6
make install
4.1.3 编译安装gperftools
从https://github.com/gperftools/gperftools/releases下载最新版本的gperftools源码包
解压到/usr/local/src目录
cd 解压源码目录
./autogen.sh
./configure
make -j6
make install
4.2 内存泄漏检测
下面是一段简单的内存泄漏源码
int main()
{
int *p = (int*)malloc(sizeof(int));
return 0;
}编译代码、运行工具检察内存泄漏,注意设置下
root@ubuntu:/home/zte/# gcc leak.cc -g
root@ubuntu:/home/zte/# env HEAPCHECK=normal LD_PRELOAD=/usr/local/lib/libtcmalloc.so ./a.out
WARNING: Perftools heap leak checker is active -- Performance may suffer
Have memory regions w/o callers: might report false leaks
Leak check _main_ detected leaks of 4 bytes in 1 objects
The 1 largest leaks:
*** WARNING: Cannot convert addresses to symbols in output below.
*** Reason: Cannot run 'pprof' (is PPROF_PATH set correctly?)
*** If you cannot fix this, try running pprof directly.
Leak of 4 bytes in 1 objects allocated from:
@ 40053f
@ 7f334da06f45
@ 400469
If the preceding stack traces are not enough to find the leaks, try running THIS shell command:
pprof ./a.out "/tmp/a.out.8497._main_-end.heap" --inuse_objects --lines --heapcheck --edgefraction=1e-10 --nodefraction=1e-10 --gv
If you are still puzzled about why the leaks are there, try rerunning this program with HEAP_CHECK_TEST_POINTER_ALIGNMENT=1 and/or with HEAP_CHECK_MAX_POINTER_OFFSET=-1
If the leak report occurs in a small fraction of runs, try running with TCMALLOC_MAX_FREE_QUEUE_SIZE of few hundred MB or with TCMALLOC_RECLAIM_MEMORY=false, it might help find leaks more repeatabl
Exiting with error code (instead of crashing) because of whole-program memory leaks
上面的关键的输入信息是：
Leak of 4 bytes in 1 objects allocated from:
@ 40053f //内存分配的指令地址
@ 7f334da06f45
@ 400469
由于工具没有直接输出问题代码行，我们通过反汇编来定位代码行：
objdump -S a.out //反汇编程序
截取汇编代码如下：
int main()
{
40052d:55 push %rbp
40052e:48 89 e5 mov %rsp,%rbp
400531:48 83 ec 10 sub $0x10,%rsp
int *p = (int*)malloc(sizeof(int));
400535:bf 04 00 00 00 mov $0x4,%edi
40053a:e8 f1 fe ff ff callq 400430
40053f:48 89 45 f8 mov %rax,-0x8(%rbp)
return 0;
400543:b8 00 00 00 00 mov $0x0,%eax我们注意到40053f就是对应代码行int *p = (int*)malloc(sizeof(int));
至此，内存泄漏的元凶被揪出来了，呵呵。
文章题目：linux程序莫名异常怎么查
标题路径：
http://kswjz.com/article/jhcicd.html
