最近项目中出现了一个问题,服务器端程序会突然崩溃退出,我们采取了coredump技术以找到崩溃原因,即确定进程退出时正在执行的函数是哪个,其状态如何。
如果系统开启了coredump,准确的说如果当前壳的环境开启了coredump,当前壳环境下的程序崩溃退出时,会把当时进程的栈的内存状态写入核心文件。使用gdb可以查看这个核心文件中保存的栈的状态,gdb。核心。(关于coredump的开启和对壳牌的理解,请参考本人另一篇博客《使用dotnet-dump查找。net核心3.0占用CPU 100%的原因解析》,关于gdb请参考《gdb调试命令的使用及总结》)
核心文件生成的位置默认是可执行文件所在的位置,名称默认为核心,其位置和名称是可以设置的,我的设置为:
这样,生成的核心文件会放在/home/corefile目录下,核心文件名会以核心- % % p - e - % t的形式出现,其中% e表示可执行文件的名称,% p表示进程,% t表示生成核心文件的时间(注意是unix时间)。
下面是一个可以导致coredump的例程:
划线处是会导致coredump处。执行后会在/home/corefile目录下产生以下文件:
a.o ut是可执行文件名,5082是PID, 1490760381是产生该文件的unix时间,把一个。出和核心文件放在一个目录下,使用命令:
<代码> gdb。核心价值。——5082 - 1490760381
进入gdb,然后使用回溯命令,即可看进程退出时的栈的内存状态,如下所示:
可见,进程退出时,执行的最后一个函数是广场函数。- - - - - - - - - - - - - - - - -
以上所述是小编给大家介绍的Linux下利用coredump技术追查进程崩溃原因,希望对大家有所帮助,如果大家有任何疑问欢迎给我留的言,小编会及时回复大家的!
