My JVM (1.6.0_29) keeps crashing on intensive use when indexing documents with Lucene.
I get:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002b6b196d767c, pid=26417, tid=1183217984
#
# JRE version: 6.0_29-b11
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J org.apache.lucene.store.DataInput.readVInt()I
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Environment:
JDK: 1.6u29 (same issue with 1.6_02)
Lucene Version 3.4.0
vm_info: Java HotSpot(TM) 64-Bit Server VM (20.4-b02) for linux-amd64 JRE (1.6.0_29-b11), built on Oct 3 2011 01:19:20 by "java_re" with gcc 3.2.2 (SuSE Linux)
OS:CentOS release 5.0 (Final)
jvm_args: -Dcatalina.home=/var/local/tomcat-8081 -Dcatalina.base=/var/local/tomcat-8081 -Djava.io.tmpdir=/var/tmp -Dfile.encoding=UTF-8 -Xmx1024M -XX:MaxPermSize=96m
It seems to be a jdk issue that was fixed in jdk 1.7, but other issues where introduced.
https://issues.apache.org/jira/browse/LUCENE-3335
"Java 7 contains a fix to the readVInt issue since 1.6.0_21 (approx, LUCENE-2975)"
So, how can I fix this issue using JDK 1.6?
Should I upgrade to jdk 1.7?
these JDK issues are also fixed in 1.6.9_29 (not only 1.7.0u1). ReadVInt can no longer crash. So your crash is not related to any of the "famous java6/7 bugs" (the vint bug does not crash your JVM at all it just corrupts your index by returning wrong values - and this one is definitely fixed since Lucene 3.1).
But there is another chance you can crash your JVM: You are on a 64 bit platform (Linux), so the default directory implementation is MMapDirectory. Lucene uses a hack to be able to unmap mapped files from virtual address space. This is not allowed by the JVM itsself, but makes unmapping dependent on garbage collector, which is a problem for Lucene. By default MMapDirectory unmaps the files after closing the IndexInputs. MMapDirectory is not synchronized at all, so when another thread tries to access the IndexInput after unmapping it will access an unmapped address and will SIGSEGV.
If your code would be correct this cannot happen, but it looks like you are using an already closed IndexReader/IndexWriter to access the index. Before Lucene 3.5 (will come out soon), missing checks in IndexReader will make it possible that an already closed IndexReader with all its closed (and unmapped) IndexInputs tries to access index data and segfaults.
In 3.5 we added additional safety checks to prevent this illegal access, but its not 100% (as synchronization is missing). I would review the code and check that nothing accesses closed index.
A simple check to see if this is your issue would be to use NIOFSDirectory (slower on Linux) instead of MMapDirectory. If it does not crash and possibly throws AlreadyClosedExceptions, the bug is accessing closed indexes.
According to this article the following could cause it in Java 6 as well:
Please note: Also Java 6 users are affected, if they use one of those
JVM options, which are not enabled by default:
-XX:+OptimizeStringConcat or
-XX:+AggressiveOpts
Are you using any of them?
Related
I received this error after more than 2 years of continous running without any problem:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fc4ec043340, pid=1143, tid=0x00007fc4bcb85700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build 1.8.0.102-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C 0x00007fc4ec043340
#
# Core dump written. Default location: /home/fportal/jaxx/leo/tomcat-7.0.42/bin/core or core.1143
#
# An error report file with more information is saved as:
# /home/fportal/jaxx/leo/tomcat-7.0.42/bin/hs_err_pid1143.log
Compiled method (c1) -1570440943 731555909 ! 1 java.text.SimpleDateFormat::subParse (1765 bytes)
Any thoughts on which could be the cause?
You have encountered a core dump:
computer program at a specific time, generally when the program has crashed or otherwise terminated abnormally
For your question: What is the root cause ?, the main issue when 2 years of continous running is a patch that has upgraded a library or the kernel (operating system), that your software, being older, doesn't know about.
So, you will have to upgrade your system with the latest, probably upgrading Apache Tomcat and or JRE (Java).
The specific issue that you've hit here is a segmentation fault when running a Java method which has been compiled; in this case, java.text.SimpleDateFormat::subParse. It's probably an error caused by a compilation of that code to native code and there being an error in that generation.
Given that the date parsing can be complex (e.g. TimeZone IDs, positive/negative offsets) it's likely it was triggered by a date format being passed in with dodgy value that would otherwise cause a NullPointerException in Java but was already compiled at a C2 level and some compilation/inlining failure has resulted in an unhandled SIGSEV.
If you find out how to reproduce it then you can raise a bug with the logs that might give a clue, but being able to reproduce it might not be practical.
Lastly, as others have noted, upgrading the JVM will get you further benefits and other fixes, so it's something worth considering.
Currently I'm trying to read serial port. Working fine in Linux. But facing error in Windows machine.
I followed this link to read serial port and Downloaded RXTX library from here for windows machine (JAR + DLL file).
OS : Windows 10 with 64bit
Java jre : Jre 1.8.0_261 VERSION.
Exception throws when read through input stream.
Error log :
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000180005b00, pid=4508, tid=0x0000000000002b90
#
# JRE version: Java(TM) SE Runtime Environment (8.0_261-b12) (build 1.8.0_261-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.261-b12 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [rxtxSerial.dll+0x5b00]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\user1\eclipse-workspace\serialport\hs_err_pid4508.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Suggessions will helpful for me. Thanks!
TL;DR: Do not use 1.8.0_261 use 1.8.0_251 instead
I tried to reproduce this error with 1.8.0_181, 1.8.0_251 and 1.8.0_261 using Windows 10.0 , 64 bit Build 18362 (10.0.18362.1082).
I could only reproduce this error with Jre 1.8.0_261. u181 and u251 worked fine for me. I would suggest to use java 8 u251 from https://www.oracle.com/java/technologies/javase/javase8u211-later-archive-downloads.html .
Serial port depending parts of the application I am working on failed today after the java update from 1.8.0_241 to 1.8.0_271. I think the problem could be the switch from Visual Studio 2010 to 2017 which Java 8 is build with now.
New Features:
➜ JDK/JRE Runtime Windows Visual Studio Library (DLL) Dependency Changes
Java 1.8.0_261 Release Notes
Update: I was on an quite old version(2017) of jssc(Java Simple Serial Connector). Unfortunately the original has no updates since a while. But I found a fork on GitHub which continues development. Whith the forked version I had no further issues!
I tested RXTX with the newer Java 8u281 release from 19 Jan. 2021 but it also crashes.
However AdoptOpenJDK 8u282 is working smoothly without any errors with the serial communication using RXTX and looks like it fully compatible with Oracle JDK!!! AdoptOpenJDK
I am getting the below error.
A fatal error has been detected by the Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000070286c80, pid=496, tid=6672
JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132)
Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b70 mixed mode windows- amd64 compressed oops)
Problematic frame:
V [jvm.dll+0x116c80]
Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
Please give the solution
In your logs, you have not the error dump because not enabled.
It looks like a bug of your JRE implementation.
You seem to use an OPEN JDK JRE implementation. If you can, try a more recent version of it or switch to an Oracle JDK/JRE implementation to check if the problem may be corrected.
Anyway, if you cannot change the version of your JDK, you can open a bug in the bug tracking site of OPEN JDK.
Failed to write core dump. Minidumps are not enabled by default on
client versions of Windows
I have two tracks :
check that you use Open JDK with a aligned version with the Open JRE.
In theory, it is not necessary but it may be a bug since you use a recent version.
No guarantee but you can try to enable it by adding the VM argument
-XX:+CreateMinidumpOnCrash in your eclipse.ini file such as :
-vmargs
-XX:+CreateMinidumpOnCrash-Xms256m
But don't duplicate the -vmargs in the file. You could have more details on the fatal error.
I have a school project that I'm working, where I fill two small arrays with data. To do this I used java.util's Arrays.fill method, which after about ten seconds would cause java to completely crash.
It was simple to fix once I pinpointed the problem by commenting out code until it worked, but I would like to know what actually caused java crash.
I tried to reproduce the crash in a smaller project, but I could not do so. So instead I've included an archive with the project in it.
I'm running lubuntu 14.04.2 x86, and the crash happens under both Oracle JDK 7.76 and Oracle JDK 8.40.
The program fails with this message, the output files are included in the archive:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb6dd9d37, pid=4458, tid=2236009280
#
# JRE version: Java(TM) SE Runtime Environment (8.0_40-b25) (build 1.8.0_40-b25)
# Java VM: Java HotSpot(TM) Server VM (25.40-b25 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x653d37] PhaseIdealLoop::match_fill_loop(IdealLoopTree*, Node*&, Node*&, Node*&, Node*&)+0x257
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
Download link to the the archive:
https://www.dropbox.com/s/wmv8xe82cwn15dg/JavaCrash.tar.gz?dl=1
So, could somebody explain what is going on? Is it my fault, or is it something out of my control?
(edit see comment) This turned out to be a bug in the JVM 8 rev. 40, released only 3 days ago. DCom library is simply a pure Java Swing wrapper.
On Mac OS JVM 6, no crash; on the same Linux machine with JVM 6, no crash. It happens. OP will attempt a report.
I am having an issue where the JRE crashes whenever I check if the GtkLookAndFeel is supported. Surprisingly, this bug only appears to show up on Oracle JREs.
So far I have tested the behavior on three JREs:
(I am using the 64 bit version of all of these)
OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-4) -> Runs fine
Java(TM) SE Runtime Environment (build 1.7.0_67-b01) -> Crashes
Java(TM) SE Runtime Environment (build 1.8.0_20-b26) -> Crashes
Here is code to trigger this bug:
import javax.swing.LookAndFeel;
public class Test
{
public static void main(String[] args)
{
LookAndFeel currLAF = new com.sun.java.swing.plaf.gtk.GTKLookAndFeel();
currLAF.isSupportedLookAndFeel();
System.out.println("I am exiting main");
}
}
Here is the resulting output:
I am exiting main
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f91fe0fdbe0, pid=332, tid=140265730119424
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C 0x00007f91fe0fdbe0
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/ethan/fail/hs_err_pid332.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
Note that the program only crashes after it exits main.
For reference, I am developing on a 64-bit debian testing machine and I have verified that other GTK+ apptications work.
Should I report this to Oracle or am I doing something wrong?
I would definitely file a bug report with Oracle. I remember something similar occurring to me many years ago. You've done your due diligence and tested on multiple runtime environments, and have identified (at least on an upper level) where the bug occurs. I would tell them everything you've done as listed here, and to be safe, run the same code on a couple different machines if you can. I know that Java should run the same either way, it's designed that way, but do it anyways so you can at least say you did that in the bug report.
Make sure you follow these guides here to collect the right information, crash dumps, system info, runtime info, etc: https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/bugreports.html
And grab the core dump if you can. The core dump will be extremely helpful (to an almost required degree) to the Oracle people for debugging what's actually happening. Here's a link to the Oracle page, but you may have to find the specific information for your machine:
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/bugreports004.html#CHDJJAJE
From the above link:
On the Linux operating system, unhandled signals such as segmentation
violation, illegal instruction, and so forth, result in a core dump.
By default, the core dump is created in the current working directory
of the process and the name of the core dump file is core.pid, where
pid is the process id of the crashed Java process.
The ulimit utility is used to get or set the limitations on the system
resources available to the current shell and its descendants. Use the
ulimit -c command to check or set the core file size limit. Make sure
that the limit is set to unlimited; otherwise the core file could be
truncated.
And this is the link to the Java Oracle Bug Reporting Site: https://bugreport.java.com/