Using the dump extractor, jextract
To use the full facilities of the dump viewer, you must first run the jextract tool on the system dump. The jextract tool obtains platform-specific information such as word size, endianness, data structure layouts, and symbolic information. It puts this information into an XML file. You must run the jextract tool on the same platform and the same JVM level (ideally the same machine) that was being used when the dump was produced. The combination of the dump file and the XML file produced by jextract allows the dump viewer (jdmpview) to analyze and display Java™ information.
-Xdump:system:defaults:request=exclusive+prepwalkSetting this option adds a significant overhead to taking a system dump; this overhead could cause problems in rare situations. This option is not enabled by default.
jextract is in the directory sdk/jre/bin.
To invoke jextract, at a command prompt type:
jextract <dumpfile> [<outputfile]
> jextract USER1.JVM.TDUMP.SSHD6.D070430.T092211 Loading dump file... Read memory image from USER1.JVM.TDUMP.SSHD6.D070430.T092211 VM set to 10BA5028 Dumping JExtract file to USER1.JVM.TDUMP.SSHD6.D070430.T092211.xml <!-- extracting gpf state --> ... Finished writing JExtract file in 5308ms Creating zip file: USER1.JVM.TDUMP.SSHD6.D070430.T092211.zip Adding "USER1.JVM.TDUMP.SSHD6.D070430.T092211" to zip Adding "USER1.JVM.TDUMP.SSHD6.D070430.T092211.xml" to zip Adding "/u/build/sdk/jre/lib/J9TraceFormat.dat" to zip jextract complete.This produces a compressed ( .zip) file in the current HFS directory.
The jextract tool accepts these parameters:
-
-nozip
- Do not compress the output data. -help
- Provides help information.
By default, output is written to a file called <dumpfile>.zip in the current directory. This file is a compressed file that contains:
- The dump
- XML produced from the dump, containing details of useful internal JVM information
- Other files that can help in diagnosing the dump (such as trace entry definition files)
Typically, you would send the compressed file to IBM® for problem diagnosis. Submitting data with a problem report tells you how to do that.
To analyze the dump locally, extract the compressed file using unzip -d dir <file> or jar xvf <file>. You are also advised to run jdmpview from that new folder.
If you run jextract on a JVM level that is different from the one for which the dump was produced, you will see the following messages:
J9RAS.buildID is incorrect (found e8801ed67d21c6be, expecting eb4173107d21c673). This version of jextract is incompatible with this dump. Failure detected during jextract, see previous message(s).
You can still use the dump viewer on the dump, but it will be limited in the detail that it can show.
The contents of the compressed file produced and the contents of the XML are subject to change, so you are advised not to design tools based on them.
Using the dump viewer, jdmpview
The dump viewer is a cross-platform tool that you use to examine the contents of system dumps produced from the JVM. To be able to analyze platform-specific dumps, the dump viewer can use metadata created by the jextract tool. The dump viewer allows you to view both Java™ and operating system information from the time the dump was produced.
jdmpview is in the directory sdk/bin.
To start jdmpview, at a command prompt type:
jdmpview dumpfile
The jdmpview tool accepts these parameters:
-
-d
<dumpfile>
- Specify a dump file. -w <workingdir>
- Specify a writable directory. -o <outputfile>
- Specify an output file. -i <inputfile>
- Specify an input command file.
Typical usage is jdmpview <dumpfile>. The jdmpview tool opens and verifies the dump file and the associated xml file, dumpfile.xml.
After jdmpview processes the arguments with which it was launched, it displays the message Ready.... When you see this message, you can start calling commands on jdmpview. You can run an unlimited number of jdmpview sessions at the same time.
jdmpview -J-Xmx<n>To pass command-line arguments to the JVM, you must prefix them with -J. For more information about using -Xmx, see Command-line options.
Parsing of xml started for file CHAMBER.JVM.TDUMP.SSHD9.D070824.T094404.xml... be patient *** Error Message: Fatal error encountered processing incoming xml.
Dump Analyzer overview
The IBM® Monitoring and Diagnostic Tools for Java™ - Dump Analyzer (referred to hereafter as the Dump Analyzer) is intended to perform automated analysis of dump files produced by the IBM Java VM. Starting with the name of the dump to be analyzed the analysis will attempt to localise the problem and if successful will produce a diagnosis of the error together with sufficient information to fix it or suggestions on how to continue the analysis using other tools (e.g. MDD4J to diagnose out of memory situations). If localization fails then the tool will default to producing summary information from the dump intended to aid further diagnosis.
Background
The Java language has come to be predominant in software development, and thus the reliability of the Java Virtual Machine (VM) has become a very important issue. The VM is typically a reliable piece of software, but of course failures do occur during execution for a variety of reasons. A small number of these problems are due to errors in the VM itself; however, in the majority of cases, they are due to errors or misconfigurations in the software stack above the VM (in WebSphere™ Application Server, for instance) or in the application itself.
The software stack for a typical projects has increased in complexity as information technology has matured, which has led to increasing difficulties for developers trying to determination the causes of problems. In such a complex environment, you may be faced with an overwhelming excess of information with which to diagnose the fault. In a production environment there may well be many gigabytes of heap, hundreds of threads, thousands of classloaders, tens of thousands of classes, and a huge number of objects.
The Dump Analyzer is an extensible framework that seeks to solve this problem for the IBM Java SDK's. It uses analyzers to interrogate a formatted system dump (each analyzer asking the dump a specific question) and links them together with a script to produce a concise report of the analysis. Typical problems analyzed might be the following.
- Out of memory
- Deadlock detected
- VM terminated due to signal (internal or middleware/java application error)
- Further investigation is required
The aim is to diagnose the correct category of problem and either provide a complete diagnosis of the problem or give some information designed to aid diagnosis together with a recommended next course of action.