Linux下core文件调试方法.docx
《Linux下core文件调试方法.docx》由会员分享，可在线阅读，更多相关《Linux下core文件调试方法.docx（16页珍藏版）》请在冰豆网上搜索。
Linux下core文件调试方法
Linuxcore文件简单介绍
时间:
2009-07-1114:
03来源:
作者:
solarisman点击:
659次
调试程序时用到的，转过来大伙共享一下
1.core文件的简单介绍
在一个程序崩溃时，它一般会在指定目录下生成一个core文件。
core文件仅仅是一个内存映象（同时加上调试信息），主要是用来调试的。
2.开启或关闭core文件的生成
用以下命令来阻止系统生成core文件:
ulimit-c0下面的命令可以检查生成core文件的选项是否打开:
ulimit-a该命令将显示所有的用户定制，其中选项-a代表“all”。
也可以修改系统文件来调整core选项在/etc/profile通常会有这样一句话来禁止产生core文件，通常这种设置是合理的:
#Nocorefilesbydefaultulimit-S-c0>/dev/null2>&1但是在开发过程中有时为了调试问题，还是需要在特定的用户环境下打开core文件产生的设置在用户的~/.bash_profile里加上ulimit-cunlimited来让特定的用户可以产生core文件如果ulimit-c0则也是禁止产生core文件，而ulimit-c1024则限制产生的core文件的大小不能超过1024kb
3.设置CoreDump的核心转储文件目录和命名规则
/proc/sys/kernel/core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展，如果添加则文件内容为1，否则为0proc/sys/kernel/core_pattern可以设置格式化的core文件保存位置或文件名，比如原来文件内容是core-%e可以这样修改:
echo"/corefile/core-%e-%p-%t">core_pattern将会控制所产生的core文件会存放到/corefile目录下，产生的文件名为core-命令名-pid-时间戳以下是参数列表:
%p-insertpidintofilename添加pid%u-insertcurrentuidintofilename添加当前uid%g-insertcurrentgidintofilename添加当前gid%s-insertsignalthatcausedthecoredumpintothefilename添加导致产生core的信号%t-insertUNIXtimethatthecoredumpoccurredintofilename添加core文件生成时的unix时间%h-inserthostnamewherethecoredumphappenedintofilename添加主机名%e-insertcoredumpingexecutablenameintofilename添加命令名
4.使用core文件
在core文件所在目录下键入:
gdb-ccore它会启动GNU的调试器，来调试core文件，并且会显示生成此core文件的程序名，中止此程序的信号等等如果你已经知道是由什么程序生成此core文件的，比如MyServer崩溃了生成core.12345，那么用此指令调试:
gdb-ccoreMyServer以下怎么办就该去学习gdb的使用了
5.一个小方法来测试产生core文件
直接输入指令:
kill-sSIGSEGV$$
coredump简介与coredump原因总结
之前写了篇日志《Linuxcore文件简单介绍》，很多人会问coredump是什么？
我们又能用coredump做什么呢？
准备写一系列这种文章对coredump做一个详细介绍
什么是coredump？
通常情况下coredmp包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理信息等。
可以理解为把程序工作的当前状态存储成一个文件。
许多程序和操作系统出错时会自动生成一个core文件。
如何使用coredump?
coredump可以用在很多场合，使用Linux,或者solaris的人可能都有过这种经历，系统在跑一些压力测试或者系统负载一大的话，系统就hang住了或者干脆systempanic.这时唯一能帮助你分析和解决问题的就是coredump了。
现在很多应该程序出错时也会出现coredump.
分析coredump的工具
现在大部分类unix操作系统都提供了分析core文件的工具，比如GNUBinutilsBinaryFileDescriptorlibrary（BFD）,GNUDebugger（gdb），mdb等
coredump的文件格式
类unix操作系统中使用efi格式保存coredump文件。
在solairs下
bash-3.2#file*unix.3ELF32-bitLSBexecutable80386Version1,staticallylinked,notstripped,nodebugginginformationavailableunix.4ELF32-bitLSBexecutable80386Version1,staticallylinked,notstripped,nodebugginginformationavailable
造成程序coredump的原因很多，这里根据以往的经验总结一下：
1内存访问越界
a）由于使用错误的下标，导致数组访问越界
b）搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符
c）使用strcpy,strcat,sprintf,strcmp,strcasecmp等字符串操作函数，将目标字符串读/写爆。
应该使用strncpy,strlcpy,strncat,strlcat,snprintf,strncmp,strncasecmp等函数防止读写越界。
2多线程程序使用了线程不安全的函数。
应该使用下面这些可重入的函数，尤其注意红色标示出来的函数，它们很容易被用错：
asctime_r（3c）gethostbyname_r（3n）getservbyname_r（3n）ctermid_r（3s）gethostent_r（3n）getservbyport_r（3n）ctime_r（3c）getlogin_r（3c）getservent_r（3n）fgetgrent_r（3c）getnetbyaddr_r（3n）getspent_r（3c）fgetpwent_r（3c）getnetbyname_r（3n）getspnam_r（3c）fgetspent_r（3c）getnetent_r（3n）gmtime_r（3c）gamma_r（3m）getnetgrent_r（3n）lgamma_r（3m）getauclassent_r（3）getprotobyname_r（3n）localtime_r（3c）getauclassnam_r（3）etprotobynumber_r（3n）nis_sperror_r（3n）getauevent_r（3）getprotoent_r（3n）rand_r（3c）getauevnam_r（3）getpwent_r（3c）readdir_r（3c）getauevnum_r（3）getpwnam_r（3c）strtok_r（3c）getgrent_r（3c）getpwuid_r（3c）tmpnam_r（3s）getgrgid_r（3c）getrpcbyname_r（3n）ttyname_r（3c）getgrnam_r（3c）getrpcbynumber_r（3n）gethostbyaddr_r（3n）getrpcent_r（3n）
3多线程读写的数据未加锁保护。
对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成coredump
4非法指针
a）使用空指针
b）随意使用指针转换。
一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。
这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为buserror而coredump.
5堆栈溢出
不要使用大的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。
LinuxCoreDump配置与调试
1.core文件的生成开关和大小限制
---------------------------------
1）使用ulimit-c命令可查看core文件的生成开关。
若结果为0，则表示关闭了此功能，不会生成core文件。
2）使用ulimit-cfilesize命令，可以限制core文件的大小（filesize的单位为kbyte）。
若ulimit-cunlimited，则表示core文件的大小不受限制。
如果生成的信息超过此大小，将会被裁剪，最终生成一个不完整的core文件。
在调试此core文件的时候，gdb会提示错误。
2.core文件的名称和生成路径
----------------------------
若系统生成的core文件不带其它任何扩展名称，则全部命名为core。
新的core文件生成将覆盖原来的core文件。
1）/proc/sys/kernel/core_uses_pid可以控制core文件的文件名中是否添加pid作为扩展。
文件内容为1，表示添加pid作为扩展名，生成的core文件格式为core.xxxx；为0则表示生成的core文件同一命名为core。
可通过以下命令修改此文件：
echo"1">/proc/sys/kernel/core_uses_pid
2）proc/sys/kernel/core_pattern可以控制core文件保存位置和文件名格式。
可通过以下命令修改此文件：
echo"/corefile/core-%e-%p-%t">core_pattern，可以将core文件统一生成到/corefile目录下，产生的文件名为core-命令名-pid-时间戳
以下是参数列表:
%p-insertpidintofilename添加pid
%u-insertcurrentuidintofilename添加当前uid
%g-insertcurrentgidintofilename添加当前gid
%s-insertsignalthatcausedthecoredumpintothefilename添加导致产生core的信号
%t-insertUNIXtimethatthecoredumpoccurredintofilename添加core文件生成时的unix时间
%h-inserthostnamewherethecoredumphappenedintofilename添加主机名
%e-insertcoredumpingexecutablenameintofilename添加命令名
3.用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生coredump了.
发生coredump之后,用gdb进行查看core文件的内容,以定位文件中引发coredump的行.
gdb[execfile][corefile]
如:
gdb./testtest.core
在进入gdb后,用bt命令查看backtrace以检查发生程序运行到哪里,来定位coredump的文件->行.
4.开发板上使用core文件调试
-----------------------------
如果开发板的操作系统也是linux，core调试方法依然适用。
如果开发板上不支持gdb，可将开发板的环境（头文件、库）、可执行文件和core文件拷贝到PC的linux下，运行相关命令即可。
注意：
待调试的可执行文件，在编译的时候需要加-g，core文件才能正常显示出错信息！
注意的问题：
在Linux下要保证程序崩溃时生成Coredump要注意这些问题：
一、要保证存放Coredump的目录存在且进程对该目录有写权限。
存放Coredump的目录即进程的当前目录，一般就是当初发出命令启动该进程时所在的目录。
但如果是通过脚本启动，则脚本可能会修改当前目录，这时进程真正的当前目录就会与当初执行脚本所在目录不同。
这时可以查看”/proc/<进程pid>/cwd“符号链接的目标来确定进程真正的当前目录地址。
通过系统服务启动的进程也可通过这一方法查看。
二、若程序调用了seteuid（）/setegid（）改变了进程的有效用户或组，则在默认情况下系统不会为这些进程生成Coredump。
很多服务程序都会调用seteuid（），如MySQL，不论你用什么用户运行mysqld_safe启动MySQL，mysqld进行的有效用户始终是msyql用户。
如果你当初是以用户A运行了某个程序，但在ps里看到的这个程序的用户却是B的话，那么这些进程就是调用了seteuid了。
为了能够让这些进程生成coredump，需要将/proc/sys/fs/suid_dumpable文件的内容改为1（一般默认是0）。
三、这个一般都知道，就是要设置足够大的Core文件大小限制了。
程序崩溃时生成的Core文件大小即为程序运行时占用的内存大小。
但程序崩溃时的行为不可按平常时的行为来估计，比如缓冲区溢出等错误可能导致堆栈被破坏，因此经常会出现某个变量的值被修改成乱七八糟的，然后程序用这个大小去申请内存就可能导致程序比平常时多占用很多内存。
因此无论程序正常运行时占用的内存多么少，要保证生成Core文件还是将大小限制设为unlimited为好。
2007-10-23|[转]浅析Linux下core文件
标签：
linuxcoredumpdebug
当我们的程序崩溃时，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。
最常出现的，几乎所有C程序员都出现过的错误就是“段错误”了。
也是最难查出问题原因的一个错误。
下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。
何谓core文件
当一个程序崩溃时，在进程当前工作目录的core文件中复制了该进程的存储图像。
core文件仅仅是一个内存映象（同时加上调试信息），主要是用来调试的。
当程序接收到以下UNIX信号会产生core文件：
名字
说明
ANSICPOSIX.1
SVR44.3+BSD
缺省动作
SIGABRT
异常终止（abort）
..
..
终止w/core
SIGBUS
硬件故障
.
..
终止w/core
SIGEMT
硬件故障
..
终止w/core
SIGFPE
算术异常
..
..
终止w/core
SIGILL
非法硬件指令
..
..
终止w/core
SIGIOT
硬件故障
..
终止w/core
SIGQUIT
终端退出符
.
..
终止w/core
SIGSEGV
无效存储访问
..
..
终止w/core
SIGSYS
无效系统调用
..
终止w/core
SIGTRAP
硬件故障
..
终止w/core
SIGXCPU
超过CPU限制（setrlimit）
..
终止w/core
SIGXFSZ
超过文件长度限制（setrlimit）
..
终止w/core
在系统默认动作列，“终止w/core”表示在进程当前工作目录的core文件中复制了该进程的存储图像（该文件名为core，由此可以看出这种功能很久之前就是UNIX功能的一部分）。
大多数UNIX调试程序都使用core文件以检查进程在终止时的状态。
core文件的产生不是POSIX.1所属部分,而是很多UNIX版本的实现特征。
UNIX第6版没有检查条件（a）和（b），并且其源代码中包含如下说明：
“如果你正在找寻保护信号，那么当设置-用户-ID命令执行时，将可能产生大量的这种信号”。
4.3+BSD产生名为core.prog的文件，其中prog是被执行的程序名的前16个字符。
它对core文件给予了某种标识，所以是一种改进特征。
表中“硬件故障”对应于实现定义的硬件故障。
这些名字中有很多取自UNIX早先在DP-11上的实现。
请查看你所使用的系统的手册，以确切地确定这些信号对应于哪些错误类型。
下面比较详细地说明这些信号。
?
SIGABRT调用abort函数时产生此信号。
进程异常终止。
?
SIGBUS指示一个实现定义的硬件故障。
?
SIGEMT指示一个实现定义的硬件故障。
EMT这一名字来自PDP-11的emulatortrap指令。
?
SIGFPE此信号表示一个算术运算异常，例如除以0，浮点溢出等。
?
SIGILL此信号指示进程已执行一条非法硬件指令。
4.3BSD由abort函数产生此信号。
SIGABRT现在被用于此。
?
SIGIOT这指示一个实现定义的硬件故障。
IOT这个名字来自于PDP-11对于输入／输出TRAP（input/outputTRAP）指令的缩写。
系统V的早期版本，由abort函数产生此信号。
SIGABRT现在被用于此。
?
SIGQUIT当用户在终端上按退出键（一般采用Ctrl-\）时，产生此信号，并送至前台进
程组中的所有进程。
此信号不仅终止前台进程组（如SIGINT所做的那样），同时产生一个core文件。
?
SIGSEGV指示进程进行了一次无效的存储访问。
名字SEGV表示“段违例（segmentationviolation）”。
?
SIGSYS指示一个无效的系统调用。
由于某种未知原因，进程执行了一条系统调用指令，
但其指示系统调用类型的参数却是无效的。
?
SIGTRAP指示一个实现定义的硬件故障。
此信号名来自于PDP-11的TRAP指令。
?
SIGXCPUSVR4和4.3+BSD支持资源限制的概念。
如果进程超过了其软CPU时间限制，则产生此信号。
?
SIGXFSZ如果进程超过了其软文件长度限制，则SVR4和4.3+BSD产生此信号。
摘自《UNIX环境高级编程》第10章信号。
使用core文件调试程序
看下面的例子：
#include
constchar*str="test";
voidcore_test（）{
str[1]='T';
}
intmain（）{
core_test（）;
return0;
}
编译：
gcc–gcore_dump_test.c-ocore_dump_test
如果需要调试程序的话，使用gcc编译时加上-g选项，这样调试core文件的时候比较容易找到错误的地方。
执行：
./core_dump_test
段错误
运行core_dump_test程序出现了“段错误”，但没有产生core文件。
这是因为系统默认core文件的大小为0，所以没有创建。
可以用ulimit命令查看和修改core文件的大小。
ulimit-c0
ulimit-c1000
ulimit-c1000
-c指定修改core文件的大小，1000指定了core文件大小。
也可以对core文件的大小不做限制，如：
ulimit-cunlimited
ulimit-cunlimited
如果想让修改永久生效，则需要修改配置文件，如.bash_profile、/etc/profile或/etc/security/limits.conf。
再次执行：
./core_dump_test
段错误（coredumped）
lscore.*
core.6133
可以看到已经创建了一个core.6133的文件.6133是core_dump_test程序运行的进程ID。
调式core文件
core文件是个二进制文件，需要用相应的工具来分析程序崩溃时的内存映像。
filecore.6133
core.6133:
ELF32-bitLSBcorefileIntel80386,version1（SYSV）,SVR4-style,from'core_dump_test'
在Linux下可以用GDB来调试core文件。
gdbcore_dump_testcore.6133
GNUgdbRedHatLinux（5.3post-0.20021129.18rh）
Copyright2003FreeSoftwareFoundation,Inc.
GDBisfreesoftware,coveredbytheGNUGeneralPublicLicense,andyouare
welcometochangeitand/ordistributecopiesofitundercertainconditions.
Type"showcopying"toseetheconditions.
ThereisabsolutelynowarrantyforGDB.Type"showwarranty"fordetails.
ThisGDBwasconfiguredas"i386-redhat-linux-gnu"...
Corewasgeneratedby`./core_dump_test'.
Programterminatedwithsignal11,Segmentationfault.
Readingsymbolsfrom/lib/tls/libc.so.6...done.
Loadedsymbolsfor/lib/tls/libc.so.6
Readingsymbolsfrom/lib/ld-linux.so.2...done.
Loadedsymbolsfor/lib/ld-linux.so.2
#00x080482fdincore_test（）atcore_dump_test.c:
7
7str[1]='T';
（gdb）where
#00x080482fdincore_tes
升级会员 