In depth analysis based on JavaCore files

  Have the time

Java programs sometimes produce JavaCore and HeapDump files when they run, which typically occurs when a Java program encounters a fatal problem.

Sometimes a Java application can continue to run without dying after a fatal problem occurs.

But sometimes fatal problems occur and the Java process dies;

In order to preserve the running state of a Java application before a fatal error occurs, the JVM produces two files, JavaCore and HeapDump, before it dies.

What is the difference between

A JavaCore is about the CPU, and a HeapDump file is about memory.

The JavaCore file basically holds where each thread of the Java application is running at any given moment, which class, which method, and which line the JVM is executing on. It is a text file that, when opened, shows the execution stack for each thread as stack trace. By analyzing the JavaCore file, we can find out whether the application is "stuck" at a certain point, that is, it runs too long at a certain point, such as database query, long time no response, and finally cause the system to crash.

A HeapDump file is a binary file that stores the usage of objects in the JVM Heap at a given time and requires analysis by tools such as IBM Heap Analyzer. The most important role of such files is to analyze whether there is a memory leak in the system.

How to generate

These two files can be generated manually, and when the system is slow or unresponsive, the JavaCore and HeapDump files can be generated manually.

On Unix/Linux, the two files are generated as follows:

    # ps -ef | grep java  
    user 4616 4582 0 17:30 pts/0 00:00:00 grep java  
    root 5580 1 0 Oct27 ? 00:02:27 /usr/bin/java -server -XX:PermSize=64M -XX:MaxPermSize=128m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/usr/local/tomcat8090/conf/logging.properties -Djava.endorsed.dirs=/usr/local/tomcat8090/endorsed -classpath :/usr/local/tomcat8090/bin/bootstrap.jar -Dcatalina.base=/usr/local/tomcat8090 -Dcatalina.home=/usr/local/tomcat8090 -Djava.io.tmpdir=/usr/local/tomcat8090/temp org.apache.catalina.startup.Bootstrap start  
    # kill -3 5580

  First, find out the Java process id, then perform the 'kill -3 process number' operation, and then do the same operation again after the file is generated to produce another set of files.

How to analyze

The JavaCore file

Two sets of documents in relation to the JavaCore particularly effective, because it can be seen in two time points, the position of thread execution, if it is found that has two sets of data in the same thread is executed in the same location, then may have a problem here, because the program is running very fast, if two are in one respect, illustrate this point are very time-consuming, and the analysis of the two files, find out the reason, then solve the problem.

There is a "Current Thread Details" tag in the header of the JavaCore file, which records the Thread id that the system runs when the JavaCore is generated. The Thread id is used to look up the Details of the Thread in the file, and the information records the JavaCore caused when the Thread runs which class.

    NULL ------------------------------------------------------------------------  
    0SECTION TITLE   subcomponent dump routine  
    NULL ===============================  
    1TISIGINFOOUTOFMEMORY received  
    1TIDATETIME Date: 2011/12/07 at 15:59:42  
    1TIFILENAME Javacore filename:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore19202086.1323298782.txt  
    NULL ------------------------------------------------------------------------  
    0SECTION XHPI subcomponent dump routine  
    NULL   ==============================  
    1XHTIME Wed Dec 7 15:59:42 2011  
    1XHSIGRECV Unexpected   signal -1 received at   0x0 in <unknown>. Processing   terminated.  
    1XHFULLVERSION J2RE 1.4.2 IBM AIX build ca142ifx-20090918 (SR13   FP2)  
    NULL            
    1XHCURRENTTHD Current Thread   Details  
    NULL ----------------------  
    2XHCURRSYSTHD "WebContainer :   5" sys_thread_t:0x45FB5328  
    3XHNATIVESTACK Native Stack  
    NULL ------------  
    3XHSTACKLINEERR unavailable -   stack address not valid  
    :::  
    :::  
    0SECTION XM subcomponent   dump routine  
    NULL ============================  
    NULL             
    1XMCURTHDINFO Current Thread Details  
    NULL ----------------------  
    3XMTHREADINFO "WebContainer : 5" (TID:0x70A8E260, sys_thread_t:0x45FB5328, state:R, native ID:0x5CC0)   prio=5 
    4XESTACKTRACE at   org.apache.taglibs.standard.tag.common.core.ImportSupport$ImportResponseWrapper.getString(Unknown   Source)  
    4XESTACKTRACE at   org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(Unknown   Source)  
    4XESTACKTRACE at   org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Unknown   Source)  
    4XESTACKTRACE at   com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(Compiled Code))  
    4XESTACKTRACE at   com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(Compiled   Code))  
    4XESTACKTRACE at   com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(Compiled Code))  
    4XESTACKTRACE at   com.ibm._jsp._part._jspService(_part.java:3237)

  This can be combined with the log file at the time to find the cause of the problem. However, this method can only find is not out of memory error, in the core file header is Java/lang/outMemoryException errors still don't know which class is executed to come when you least expect them to.

Heapdumps file
A HeapDump file is a snapshot of the Java stack at a given moment, which is a mirror file. The Heap Analyzer tool finds objects that cause or may cause memory leaks by analyzing the HeapDump file to see which objects take up too much stack space.