Segfault error - Confluence unavailable due to Java crash
This page serves as a starting point reference in the case of a java issue. It will also be suggested if your logs are scanned and found an older version of java running. It is recommended that you use the latest jdk that is compatible with your version of Confluence.
Note this link takes you to the document for the most recent version of Confluence. Select the desired version from the left navigation to see compatible jdk's for older versions.
- The Java process is not running. It was not shut down manually.
- Confluence (and other applications running on the JVM) become unavailable. Catalina.out or logs in the /var/log/messages may contain:
# # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xfe9bb960, pid=20929, tid=17 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_01-b08 mixed mode) # Problematic frame: # V [libjvm.so+0x1bb960\] # T H R E A D Current thread (0x01a770e0): JavaThread "JiraQuartzScheduler_Worker-1" [_thread_in_vm, id=17\] siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000 Registers: O0=0xf5999882 O1=0xf5999882 O2=0x00000000 O3=0x00000000 O4=0x00000000 O5=0x00000001 O6=0xc24ff0b0 O7=0x00008000 G1=0xfe9bb80c G2=0xf5999a48 G3=0x0a67677d G4=0xf5999882 G5=0xc24ff380 G6=0x00000000 G7=0xfdbc3800 Y=0x00000000 PC=0xfe9bb960 nPC=0xfe9bb964 ....
The following may appear in the
[ERROR\] Thu Apr 08 11:43:05 PDT 2010 [com.atlassian.renderer.v2.V2Renderer\] Unable to render content due to system error: null Throwable: java.lang.StackOverflowError at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:698) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1817)
Check to confirm that Java has itself crashed.Linux
Run ps -aux | grep javaWindows
Hit ctrl-alt-delete and check for java.exe in the running programs.
Search the system for files named hs_err_pid*. Otherwise, look in /var/log/messages for a segmentation fault message. The SIGSEGV message indicates Java itself is crashing.
/var/log/messages:Jun 25 03:33:13 wiki1 kernel: java: segfault at 0000000045f79fd8 rip 00002ad5878d6943 rsp 0000000045f79fd0 error 6
- JVM crashes often appear when the JVM is running out of memory. The
hs_err_pid*.logfile should list the state of memory at the time of the crash. If the JVM was low on memory, then it's a good idea to read the Confluence crashes due to 'OutOfMemoryError Java heap space' error page and follow the suggestions there.
- This is usually caused by a bug in the JVM, but in some cases, a Stack Overflow can cause the outage.
- This may be due to the excerpt-include macro running recursively. See CONF-15247 for a resolution. This bug is fixed in Confluence 3.2. Upgrade to 3.2 or later.
- Another cause is a bug in the C2 (Server) compiler shipped in the Oracle 1.6 JDK for versions 18 and 19 (at the time of writing). This bug causes the JVM to exhaust the address space of the process. This affects both 32bit and 64bit versions of the JVM.
Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV. This bug has been reported affecting versions back to 1.6.0_24. Link to Oracle bug report
- Upgrade Java environment
- If you are experiencing Confluence crashes due to 'OutOfMemoryError Java heap space' error errors, ensure to follow the guidelines for adjusting the memory allocation to the JVM.
Ensure that your operating system is a Supported Platforms, and (especially for Solaris) ensure that the operating system has all current required patches applied.
Still having problems?
If you have disabled the excerpt-include and excerpt macros as described in the workaround in CONF-15247 and have changed your JDK version, here are the next steps:
- If running on a Virtual Machine (VM) move to a physical server and check to see if you can reproduce the problem (the bug may be specific to your VM).
- If you are using a 64bit JVM, try switching to 32bit. When doing so reduce your memory to -Xmx2048m as you cannot allocate more than this to a 32bit JVM.
- Follow the suggestions in Garbage Collector Performance Issues.
- Check CONF-19049 for further information and user contributions.