When the JRockit JVM or Java application becomes unresponsive but has not crashed, it is considered to be frozen: the application stops responding to requests but the process still exists.
This chapter describes how to diagnose a freezing JVM and how to collect information that is essential for Oracle Support personnel to resolve the problem.
This chapter contains the following topics:
A system can freeze in either the JVM or the application. To determine whether the freeze is occurring in the application or in the JVM, try to generate a thread dump.
On Windows, press Ctrl-Break.
On Linux and Solaris, send SIGQUIT (kill -3) to the parent Java Process ID.
Note:
Alternatively, on all platforms, you can obtain the thread dump by usingjrcmd; for example:
jrcmd nnnn "print_threads nativestack=true"
nnnn is the ID of the Java process. To view a list of the IDs of all Java processes running on the machine, run jrcmd without any command-line parameters.
If the system responds with a Java thread dump, then the application is freezing. For information about troubleshooting this type of freeze, see Section 7.2, "Troubleshooting a Java Application Freeze."
If you cannot obtain a thread dump, the JVM is freezing. For information about troubleshooting this type of freeze, see Section 7.3, "Troubleshooting a JVM Freeze."
Review the thread dumps (look near the end of the thread dump) for locks and deadlocks.
If you cannot determine the cause of the freeze or if you cannot fix the problem easily by yourself, contact the developer of the application.
If neither you nor the application developer are able to diagnose the problem, contact Oracle Support as described in Chapter 9, "Contacting Oracle for Support." When you contact Oracle Support about a Java application freeze, provide the following information:
Three thread dumps from the application when it works fine.
Three thread dumps from the application when it has frozen.
One 120s Flight Recorder recording from the application when it works fine.
One 120s Flight Recorder recording from the application when it has frozen.
If you cannot get thread dumps with Ctrl-Break or by sending SIGQUIT (kill -3) to the parent Java process ID after a few attempts, the JVM has stopped handling signals and is freezing.
When this happens, you should force the JVM to crash and then contact Oracle Support for help. The crash file is essential for Oracle Support personnel to diagnose and troubleshoot the problem.
This section describes how you can force a frozen JRockit JVM to crash. It contains the following topics:
You can force a frozen JRockit JVM on a Linux system to crash by sending a SIGABRT signal, which aborts the process and causes a crash, thus producing a crash file.
To invoke SIGABRT, perform the following steps:
Find the process ID of the JRockit JVM process, by running the following command:
Note:
The following instructions are valid on 2.6 kernel-based Linux systems and on Red Hat Enterprise Linux 3.0 (or later versions).
pstree -p user | grep java
In this command, user is the Linux username (for example, webadmin) used to run the JRockit JVM process.
If the command results in excessive output, try unsetting the LANG environment variable first, by running unset LANG.
If the command shows only one Java process, proceed to step 2.
If the command shows several processes, print the command-line parameters for the required process, by running the following command:
cat /proc/nnnn/cmdline | xargs --null -n1 echo
In this command, nnnn is the ID of the JRockit JVM process.
This command displays the command-line options for the specified JVM process. Check whether any of the command-line options could be causing the problem.
Find out the directory in which the binary crash file (.core) for the process will be created, by entering the following command:
ls -l /proc/nnnn/cwd
In this command, nnnn is the ID of the JRockit JVM process.
Create the binary crash file (and terminate the process) by running the following commands:
ulimit -c unlimited
kill -SIGABRT nnnn
In this command, nnnn is the ID of the JRockit JVM process.
You can force a frozen JRockit JVM on a Windows system to crash by using the windbg command, as follows:
windbg.exe -Q -pd -p nnnn -c ".dump /u /ma hung.mdmp; q"
In this command, nnnn is the ID of the JRockit JVM process.
Note:
windbg is included in the Debugging Tools for Windows package that you can download from:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
If the JRockit JVM starts as a service, you can collect thread dumps by doing one of the following:
If you are collecting information from your own machine, run jrcmd with the print_threads diagnostic command.
For more information about the jrcmd command, see the Oracle JRockit JDK Tools.
If you are collecting information from another machine, use Oracle JRockit Mission Control with the diagnostics bean. For more information, see the Oracle JRockit Mission Control Online Help.
If you run the JRockit JVM with Oracle WebLogic Server, you can use beasvc –dump to obtain thread dumps from the JVM.
For more information, see the Oracle WebLogic Server documentation.
If you want to see the messages that a server instance prints to stdout and stderr (including stack traces and thread dumps), redirect stdout and stderr to a file, see the Oracle WebLogic Server documentation.
To make the WebLogic Server instance print a thread dump to stdout, do one of the following:
Use the weblogic.Admin THREAD_DUMP command.
Enter the following command at the command prompt:
WL_HOME\bin\beasvc -dump -svcname:service-name
In this command, WL_HOME is the directory in which you installed WebLogic Server and service-name is the Windows service that is running a server instance; for example.:
D:\Oracle\Middleware\wlserver_10.3\server\bin\beasvc -dump -svcname:mydomain_myserver