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.
Related
A while ago I opened up my computer to work on a Minecraft mod I had been working on, but instead of running like normal, I got this exception:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffbb88537e0, pid=18248, tid=9400
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.4.1+1 (17.0.4.1+1) (build 17.0.4.1+1)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.4.1+1 (17.0.4.1+1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C [atio6axx.dll+0x1937e0]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\Name\Desktop\SurvivalSnacks\run\hs_err_pid18248.log
#
# If you would like to submit a bug report, please visit:
# https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
After trying to find out what was happening for a few hours, I realized it wasn't a problem with my code. I tried running other java programs I had made. A simple Hello World program worked, but my LWJGL game crashed with the same exception, and any program that I used file IO crashed with File Not Found. The IO program also worked for other people that were working on the same project through GitHub.
The log from IntelliJ is too long to post in the question, so I used some website that posts text: https://jpst.it/2-biQ
Some things I tried:
Reinstalling IntelliJ
Reinstalling JDK
Running IntelliJ as admin
Factory Resetting my PC
All of the above things resulted in the same error
I also found this Stack overflow with a very similar problem to mine, but the solution did not work for me.
JVM Crash - "EXCEPTION_ACCESS_VIOLATION"
I fixed the problem by going to my graphics card company and downloading a version from before the error started happening. Just rolling back didn’t work because rolling back only let me go back one version, I had to go back to an update from 5 months ago.
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 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/
Someone knows why eclipse close when i click any button. This is because when i try to do something, update eclipse or whatever, eclipse close and it gives me this log...
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fc329864f7a, pid=9392, tid=140476827293968
#
# JRE version: 6.0_16-b01
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 )
# Problematic frame:
# C [libpango-1.0.so.0+0x24f7a] pango_layout_new+0x2a
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
I think it is something about java, anyone has any solution?¿
Thanks
To sum up the discussion ki0 linked to, you can get around the problem in eclipse 3.5.1 by replacing the org.eclipse.swt.gtk.linux.*.jar from your eclipse/plugins directory with the one at http://launchpadlibrarian.net/36500083/org.eclipse.swt.gtk.linux.x86_3.5.1.v3555a.jar.
I already had the 3.5.2 version installed, so that didn't help me, but the discussion on the linked eclipse bug at https://bugs.eclipse.org/bugs/show_bug.cgi?id=291128 prompted me to download the latest 3.5.x eclipse version for the fix. That Amazon Web Services mirror is nice and fast. =)