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/
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.
Abruptly last afternoon, my Java (Groovy, actually) started hanging in ClassLoader.load(String, boolean) while trying to call ImageIO.read(file). The stack trace indicated it was trying to load AWT related code.
In case it was an IntelliJ or Gradle issue I tried the command-line, where it still hung, but successfully ran past that point if I specified -Djava.awt.headless=true, apparently related to the -XstartOnFirstThread SWT 2013 bug, but of course that meant I was unable to display windows from the program.
This obtained even with a trivial 'only load an image' program.
Contrarily, an existing Java-based application ran happily, and a brand new user on the same machine had no problems.
Moving all my account's . files and logging out/in, and checking my environment variables for suspicious things compared with the brand new user had no effect.
I don't know precisely WHY this was happening, but it relates directly to having previously suffered a native crash:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000131099b1b, pid=11165, tid=4867
#
# JRE version: Java(TM) SE Runtime Environment (8.0_31-b13) (build 1.8.0_31-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.31-b07 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libtesseract.dylib+0x156b1b] ELIST::length() const+0x5
#
# 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:
# /Users/tim/git/t4jhack/hs_err_pid11165.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.
#
because I just triggered it again, and the issue resurrected immediately.
The app crash says
AppMain quit unexpectedly.
Click reopen to open the application again.
This report will be sent to Apple automatically
[show details] [OK] [Reopen]
I clicked 'OK' and 'Reopen' variously - both cause the problem.
The 'fix' I stumbled across:
In System Preferences, open the Java Control Panel, where it will say:
The last time you opened Java, it unexpectedly quit while reopening windows.
Do you want to try to reopen its windows again?
If you choose not to reopen windows, you may have to open and
position the windows yourself.
[don't reopen] [reopen]
You want 'Reopen', then just OK the resulting window.
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 have a problem with JavaFX desktop application, specifically with 3d rendering functionalities.
Every time I try to build and launch JavaFX application, JVM crshes and I get error similiar to following one:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=8440, tid=9008
#
# JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C 0x0000000000000000
#
# 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:
# D:\apps\desktop\hs_err_pid8440.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Entire log: http://pastebin.com/FC6NfVjF
I tried different java version (1.7_51, 1.7_60, as well as 1.8_5), I tried updating graphic card drivers.
Some project does launch, but as soon as I want to display some 'more complicated' effects (i.e. hovering a button), I get the same exception.
Judging from the stacktrace, I believe it has something to do with directX.
j com.sun.prism.d3d.D3DVertexBuffer.nDrawIndexedQuads(J[F[BI)I+0
j com.sun.prism.d3d.D3DVertexBuffer.drawQuads(I)V+13
j com.sun.prism.impl.VertexBuffer.flush()V+12
I'm working on machine with Windows 8.1 and DirectX 11. Probably it won't help, but here I'm also pasting DirectX Diagnostic Tool log:
http://pastebin.com/giN4AFv4
Thanks for any input.
The crash has happened inside C:\Windows\system32\igdumdim64.dll at offset 0xe5fe9.
This library is a part of Intel HD Graphics Driver.
Here is a quick tip how to find this from the crash log.
# Problematic frame:
# C 0x0000000000000000
Zero instruction pointer means there was an indirect call, and the target address happened to be NULL. The return address for this call is likely to be on the top of stack.
Top of Stack: (sp=0x000000000ef4d398)
0x000000000ef4d398: 00007ffb308b5fe9 000000000e979800
00007ffb308b5fe9 is the saved return address. Let's find the range it belongs to.
Dynamic libraries:
...
0x00007ffb307d0000 - 0x00007ffb31019000 C:\Windows\system32\igdumdim64.dll
Find the offset in the library by subtracting the base address:
0x00007ffb308b5fe9 - 0x00007ffb307d0000 = 0xe5fe9
Next, having the dll in hand, we can disassemble it and figure out the exact function at the given offset.
P.S.
There is also a Windows-specific Java flag -XX:+CreateMinidumpOnCrash that helps to produce a more meaningful crash dump for analysis.
I have the following setup:
Hadoop 1.2.1
Oracle Java 1.7
Suse Enterprise Server 10 32bit
If I execute the Pi-example in standalone mode with
bin/hadoop jar hadoop-examples-1.2.1.jar pi 10 10
then Java dies the hard way, telling me
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGFPE (0x8) at pc=0xb7efa20b, pid=9494, tid=3070639008
#
# JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
# Java VM: Java HotSpot(TM) Server VM (24.0-b56 mixed mode linux-x86 )
# Problematic frame:
# C [ld-linux.so.2+0x920b] do_lookup_x+0xab
#
# 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:
# /opt/hadoop-1.2.1-new/hs_err_pid9494.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
(The full trace is here)
On a distributed setup, i can start-all components and they are ideling fine. But when I submit a job, then the jobtracker dies immediately with an java.io.EOFException, I assume this is due to the same error as above.
I have already tried the same hadoop on another computer, there everything is fine (altough this one runs Arch Linux 64bit), and other Javas (OpenJDK, 1.6, 1.7) don't help.
Any suggestions?
Probably Hadoop includes a native library that was either compiled for a different platform (e.g. 64 bit instead of 32 bit), or the library expects a different environment. The stack trace also shows that JVM_LoadLibrary() is trying to load a native lib.
Make sure you downloaded the correct version of Hadoop for your platform, or compile it yourself for your target platform.