在Unix系统下,应用程序崩溃,一般会产生core文件,如何根据core文件查找问题的所在,并做相应的分析和调试,是非常重要的,本文对此做简单介绍。
例如,一个程序cmm_test_tool在运行的时候发生了错误,并生成了一个core文件,如下:
-rw-r–r– 1 root cmm_test_toolc
-rw-r–r– 1 root
cmm_test_toolo
-rwxr-xr-x 1 root cmm_test_tool
-rw--- 1 root
core19344
-rw--- 1 root core19351
-rw-r–r– 1 root
cmm_test_toolcfg
-rw-r–r– 1 root cmm_test_toolres
-rw-r–r– 1 root
cmm_test_toollog
[root@AUTOTEST_SIM2 mam2cm]#
就可以利用命令gdb进行查找,参数一是应用程序的名称,参数二是core文件,运行
gdb
cmm_test_tool core19344结果如下:
[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core19344
GNU gdb Red Hat
Linux (521-4)
Copyright 2002 Free Software Foundation, Inc
GDB is free
software, covered by the GNU General Public License, and you are
welcome to
change it and/or distribute copies of it under certain conditions
Type “show
copying” to see the conditions
There is absolutely no warranty for GDB Type
“show warranty” for details
This GDB was configured as
“i386-redhat-linux”…
Core was generated by `/cmm_test_tool’
Program
terminated with signal 11, Segmentation fault
Reading symbols from
/lib/i686/libpthreadso0…done
Loaded symbols for
/lib/i686/libpthreadso0
Reading symbols from
/lib/i686/libmso6…done
Loaded symbols for /lib/i686/libmso6
Reading
symbols from /usr/lib/libzso1…done
Loaded symbols for
/usr/lib/libzso1
Reading symbols from
/usr/lib/libstdc++so5…done
Loaded symbols for
/usr/lib/libstdc++so5
Reading symbols from
/lib/i686/libcso6…done
Loaded symbols for /lib/i686/libcso6
Reading
symbols from /lib/libgcc_sso1…done
Loaded symbols for
/lib/libgcc_sso1
Reading symbols from /lib/ld-linuxso2…done
Loaded
symbols for /lib/ld-linuxso2
Reading symbols from
/lib/libnss_filesso2…done
Loaded symbols for /lib/libnss_filesso2
#0
0×4202cec1 in __strtoul_internal () from
/lib/i686/libcso6
(gdb)
进入gdb提示符,输入where,找到错误发生的位置和堆栈,如下:
(gdb) where
#0 0×4202cec1 in __strtoul_internal () from
/lib/i686/libcso6
#1 0×4202d4e7 in strtoul () from
/lib/i686/libcso6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2,
max_id=0×806fd20) at cmm_test_toolc:788
#3 0×0804b9d7 in ConstrctVODProgram
(vod_program=0×40345bdc) at cmm_test_toolc:946
#4 0×0804a2f4 in
TVRequestThread (arg=0×0) at cmm_test_toolc:372
#5 0×40021941 in
pthread_start_thread () from /lib/i686/libpthreadso0
(gdb)
至此,可以看出文件出错的位置是函数 GetMaxIDFromDB
,两个参数分别是2和0×806fd20,这个函数位于源代码的788行,基于此,我们就可以有针对性的找到问题的根源,并加以解决。
可以重新下载一个aifcoredll文件,然后按如下步骤 *** 作:
解压后直接拷贝该文件到系统目录里:
Windows 95/98/Me系统,复制到C:\Windows\System目录下。
Windows NT/2000系统,复制到C:\WINNT\System32目录下。
Windows XP/WIN7/Vista系统,复制到C:\Windows\System32目录下。
根据系统的位数将文件复制到C:\Windows\SysWOW64目录二、打开"开始-运行-输入regsvr32 aifcoredll",回车即可解决。
在Linux上只要打开core dump文件开关,当程序crash时系统生成相应的core文件。下面是简单的一些步骤: 1查看当前是否已经打开了此开关 通过命令:ulimit -c 如果输出为 0 ,则代表没有打开。如果为unlimited则已经打开了,就没必要在做打开。
系统中,应用程序崩溃,一般会产生core文件,如何根据core文件查找问题的所在,并做相应的分析和调试,是非常重要的。
什么是Core Dump
Core的意思是内存, Dump的意思是扔出来, 堆出来开发和使用Unix程序时, 有时程序莫名其妙的down了, 却没有任何的提示(有时候会提示core dumped) 这时候可以查看一下有没有形如core进程号的文件生成, 这个文件便是 *** 作系统把程序down掉时的内存内容扔出来生成的, 它可以做为调试程序的参考
core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由 *** 作系统把程序当前的内存状况存储在一个core文件中, 叫core dump
COREDUMP是由系统全局设置和程序设置后才能生成的,当发生异常时,由内核将程序映像转储,和GCC和GDB没有直接关系,GCC中加-g参数是为了获得符号表,便于GDB分析,一般只包含一个线程的TRACE,COREDUMP所反馈的信息也不是完全准确的,它只是程序宕机前的一个映像(主要是调用堆栈及全局量),如果程序跑飞了那参考价值就不大了。
为什么没有core文件生成呢
有时候程序down了, 但是core文件却没有生成 core文件的生成跟你当前系统的环境设置有关系, 可以用下面的语句设置一下, 然后再运行程序便成生成core文件
ulimit -c unlimited(将coredump文件设置位无限制)
可用ulimit -a命令查看系统限制,如果此时的core file size (blocks, -c) 0则不会产生core文件。
core文件生成的位置一般于运行程序的路径相同, 文件名一般为core进程号
当获得了core文件以后,就可以利用命令gdb进行查找,参数一是应用程序的名称,参数二是core文件
如: gdb []xmsd []/xmsd_PID1065_SIG11core
然后输入bt或者where找到错误发生的位置和相应的堆栈信息。就可知道发生错误时的函数调用关系,然后可以使用up或者down查看上一条和下一条具体详细信息。这样便能对问题进行大概定位,然后看源代码,进行分析。
例程:
$vi fooc
编辑如下:
#include <stdioh>
static void sub(void);
int main(void)
{
sub();
return 0;
}
static void sub(void)
{
int p = NULL;
/ derefernce a null pointer, expect core dump /
printf("%d", p);
}
$more fooc //查看代码
$gcc -Wall -g fooc
$/aout
段错误
当core file size (blocks, -c) 0时,不会有core文件生成,但是我们已经设置位unlimited,所以在ls查看的时候:
aout core fooc
然后使用GDB进行解析
$gdb --core=core
GNU gdb (GDB) 71-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc
License GPLv3+: GNU GPL version 3 or later <>
以上就是关于core文件如何查看和调试全部的内容,包括:core文件如何查看和调试、系统显示“无法启动此程序,因为计算机中丢失aif_core.dll,尝试重新安装该程序”怎么解决、linux程序怎么生成core等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)