最近遇到了一个Java项目出现了几次coredump报警,报警如下:
coredump文件是由于程序存在异常或者bug导致程序意外终止产生的文件。coredump文件会包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息还有各种函数调用堆栈信息等信息。
coredump的文件存储位置以及文件名称可以在/proc/sys/kernel/core_pattern下配置。
要是在文件意外退出没有生产coredump文件可以用命令“ulimit -a”查看core file size 是不是为0。
首先、使用命令“gdb $JAVA_HOME/bin/java coredump文件”进入gdb调试页面,页面如下:
此时gdb已经显示由于在执行block_size方法发生了段错误。在当前gdb调试环境中使用明明where/bt可以查看当前运行的堆栈列表,如下:
可以看出在读取zip文件时候发生了问题,我们可以使用info threads查看当前可调试的所有线程,找到发生错误的线程Id(233161),具体如下:
然后退出gdb 调试页面。
然后、使用命令“$JAVA_HOME/bin/jstack $JAVA_HOME/bin/java coredump文件”查看当前所有的线程栈信息,找到线程Id=233161的具体线程栈信息,如下:
这样就能定位到具体的位置了。
当然如果发生coredump不是由于Java线程引起的(比如GC线程),用jstack可能就找不到该线程信息。那此时也能够有gdb的bt查看native线程栈的内容了去确定具体的问题了。