【技能库】--jvm crash 如何开启 core dump 如何分析（280）

1.core dump介绍

        程序异常退出（crash）时会自动生成一个core文件，包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理等信息，也就是把程序当时工作的状态存储成一个文件。不仅仅是在出错的时候会生成core dump文件，在系统卡住或者cpu使用率很高的时候也可以手动触发生成core dump文件（当然这种情况也可以直接通过jmap和jstack dump出内存和线程堆栈，但JDK1.6以前，这2个命令经常执行不成功），这样就可以很好的分析了。

2.生成core dump文件

       core dump文件生成开关其实是通过对生成的文件大小进行控制达到的，默认大小是0，也就是说默认是不生成core dump文件的，可以通过命令ulimit -c进行查看。将此参数修改成unlimited就可以生成core dump文件了，但值得注意的一点是，每个应用进程都会读取自己的一套系统参数，可以查看进程对应的内存文件/proc/<pid>/limits中的信息来判断修改后的参数值是否对此应用进程生效了，limits文件中的信息如下：

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        unlimited           unlimited            bytes    
Max resident set          unlimited            unlimited            bytes     
Max processes             20480                20480                processes 
Max open files            204800               204800               files     
Max locked memory         32768                32768                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       1024                 1024                 signals   
Max msgqueue size         819200               819200               bytes

      上述信息中的对应的参数值为unlimited，代表此应用进程的core dump开关是开着的。ulimit -c unlimited这个命令可以在很多地方修改，比如用root在命令行执行，在/etc/profile中增加（/etc/profile文件中已经有defaultulimit -S -c 0 > /dev/null 2>&1，可以直接修改0为unlimited），在用户的.bash_profile中增加..这些方式执行后的影响范围还是挺复杂的，到现在也没弄清楚。当时通过root用户命令行修改后，在shell里查询ulimit -c是生效了，以为应用程序也生效了，觉得不用应用都不需要重启就生效了挺好，等到下一次crash的时候发现还是没有生成core dump文件，于是到文件/proc/<pid>/limits中检查此参数值才发现应用程序所读取的值还是0。后来采用一种比较简单直接的方式，用root用户修改/etc/profile文件中的ulimit -c的值，然后重新登录，重启应用，再检查/proc/<pid>/limits中的值，确保参数已经生效，后来应用再crash时core dump文件也如期而至，心里暗爽，终于可以开始分析堆栈了。

       core dump文件生成的默认路径在用户的工作目录（启动脚本目录），可以通过设置参数/proc/sys/kernel/core_pattern的值改变core dump文件的最终生成路径及文件名格式。core dump文件成功后，在jboss控制台错误日志中的日志也多了core dumped关键字，如下：

/opt/.../jboss/bin/run.sh: line 181:  9176 段错误                  (core dumped) "$JAVA" $JAVA_OPTS -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" -classpath "$JBOSS_CLASSPATH" org.jboss.Main "$@"

3.core dump分析

参考：http://blog.csdn.net/cpzhong/article/details/7191811