For a university assessment we're doing a large java project which makes use of a given external hardware that utilises a given java library to interact with it.
The main problem is that such java library only runs on java 1.8 (the reason is not clear yet) and just fails with newer versions of java.
Since the rest of the code (a few thousands) is written in java 9, it's obviously a hard task to rewrite everything without making uses of all the functionalities added since java 1.8
I have the following questions:
Is there a way to make the whole project back-compatible without changing thousands of lines of code? (or to make the library work with a newer version of java)
In the case there isn't such way, is there an easy way to see what needs to be changed to make the project compatible with a previous version of java?
Thank you in advance for any answer, any small contribution will be a great deal for us
Error stack trace:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000180005b00, pid=20224, tid=10952
#
# JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [rxtxSerial.dll+0x5b00]
#
# 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\works\Documents\GitHub\Software-Engineering\src\hs_err_pid20224.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.
Related
This question already has answers here:
Why do I keep getting this SIGBUS error code on my MacOS when trying to run a JavaFx Project on Netbeans?
(2 answers)
Closed 1 year ago.
Hello everyone I receive and error when running a GUI application on JAVAFX on IntelliJ. I'm in my second semester with Java in college so now really sure what these errors mean but basically the program runs for a few seconds and then suddenly crashes on it's own. It's all random, can last 3 seconds or can last 15 seconds. I'm not sure what information is needed but I can provide for now what I'm using which is Java 17 and JAVAFX up to date. Mac mini M1. Intellij up to date.
#
# SIGBUS (0xa) at pc=0x000000010a0514f0, pid=8179, tid=28687
#
# JRE version: Java(TM) SE Runtime Environment (17.0.1+12) (build 17.0.1+12-LTS-39)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0.1+12-LTS-39, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# v ~StubRoutines::SafeFetchN
#
# No core dump will be written. 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/yayo/Documents/CSC 123/Projects/HeadsOrTails/hs_err_pid8179.log
#
# If you would like to submit a bug report, please visit:
# https://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.
#
# The crash happened outside the Java Virtual Machine in native code.
This is a broken configuration - not your code. An external library is being called by the JVM which causes the crash. You might need to update that manually. The error file written contains more troubleshooting information.
I am having real problems getting to the bottom of the java hotspot errors we are experiencing. The errors are seemingly random and the problematic frame varies. An example error is shown below:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f65ce3c3a84, pid=26082, tid=0x00007f65bc2ab700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_101-b13) (build 1.8.0_101-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.101-b13 mixed mode linux-amd64 )
# Problematic frame:
# V [libjvm.so+0x5c3a84] G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*)+0x174
#
# Core dump written. Default location: /opt/dap/domains/tc0419/prod1/tomcat/bin/core or core.26082 (max size 1 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
The java application is a relatively simple, it is just a war file running in a tomcat on a server.
Please let me know if any additional information would be helpful to access, I'm a bit new to this. The current thinking is that this is a hardware issue but any further information would be much appreciated.
Thanks,
Adam
The problematic frame "G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*)+0x174" represents it is an gc crash. It is bug in JVM. There are couple of issues reported before
1. https://bugs.openjdk.java.net/browse/JDK-8170451
2. https://bugs.openjdk.java.net/browse/JDK-8143310
As we don't have way to reproduce or they occured once in a while. As you can see both the issues are closed either as Incomplete or cannot reproduce.
If you have a strong reproduce kindly file a bug through http://bugreport.java.com/submit_intro.do along with steps/test case to reproduce the issue.
It will be addressed... :)
You are using JDK 8 update 101, Kindly upgrade to latest build JDK8 update 121 from here - http://www.oracle.com/technetwork/java/javase/downloads/index.html
I'm working on a CD burner using java, where ( using JNI ) i must load some native libraries (DLL). Well, i know that to load a native library using "System.loadLibrary(libName)", the library must be set to one of the "java.library.path" paths, however if using "System.load(libPath)" there is no need for that.
So, i used to load all my native libraries using "System.load(libPath)" and that worked for all of them except a single one "BurnerCaller.dll" that causes a JVM crash with the error message below.
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (0xe0434352), pid=2280, tid=0x00000000000013a8
#
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [KERNELBASE.dll+0xaa7d]
#
# 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:\Program Files\Java\MainWorkspace\NewAman\hs_err_pid2280.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.
Here is the detailed result error.
The weird thing is that if and only if i put this library to the "bin" directory of the currently running JRE or JDK (that my application is using to run) it works like a charm.
Any help would be appreciated, thanks in advance.
Try other JDK (Oracle JDK, Open JDK, versions 6,7,8). make sure dll bitness (32 vs 64) match JDK bitness
Debug native code
It looks like pure native problem and you should use native tools.
If you have source code of BurnerCaller.dll you can attach(Visual Studio, WinDbg)\debug\fix it. At least you will see the stacktrace of native crash.
If you don't have the souce - just put it in java bin directory, the easiest way.
When system loader loads a library, it calls DllMain for this library, looks like the bug is somewhere around it.
I recently downloaded the zip file of spring tool suite(3.7.0) from it's official web page(https://spring.io/tools/sts/all). After unzipping it and double clicking the sts.exe file, it asks for the namespace. After that when sts loads, the dashboard appears but after few seconds the application crashes. I'm getting the following error popup..
And also a log file is generated whose first few lines are..
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ILLEGAL_INSTRUCTION (0xc000001d) at pc=0x000007fee5f4ca90, pid=5020, tid=3860
#
# JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [msvcr120.dll+0x8ca90]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# 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.
#
I can't seem to understand where I am going wrong. I installed both 32, 64 bit JDK on my machine just in case but still nothing. Is it because windows did not install properly on my laptop?? Please help..
EDIT 1:
In response to #Pendlimarri's comment below, the different forms of Java installed in my control panel are..
I too got the same problem. I fixed by uninstalling the 1.8.0_60 update from Control Panel.
This might be a bug in 1.8.0_60.
FWIW, it's probably because STS is 32-bit and your JDK is 64-bit - change one or the other and it should work
Anyone have GWT 1.6.4 running on FreeBSD? Our build server is a FreeBSD box, and dies with the following when we try to compile:
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000800d0c724, pid=4749[thread 34370233088 also had an error], tid=0xa02d80
#
# Java VM: Diablo Java HotSpot(TM) 64-Bit Server VM (10.0-b23 mixed mode bsd-amd64)
# Problematic frame:
# V [libjvm.so+0x20c724]
#
# An error report file with more information is saved as:
# /usr/home/username/reporting/hs_err_pid4749.log
#
# Please submit bug reports to freebsd-java#FreeBSD.org
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
Interestingly, Maven seems to include gwt-dev-1.6.4-linux.jar in the classpath, presumably because there is no version for FreeBSD; I don't know if this is related or not. We are just trying to compile, not use hosted mode, so I don't believe any native libraries are actually required. This used to work fine for us with GWT 1.5.
If you search Google for that frame (libjvm.so+0x20c724) you find some relevant recent threads on the freebsd-java list.
Looks like the problem might be related to IPv6? The solution proposed there was to add
-Djava.net.preferIPv6Addresses=false
-Djava.net.preferIPv4Stack=true
to the configuration.
It's unusual to see a FreeBSD build system for java; there isn't a lot of flexibility or support for Java on that platform. Is your product deployed on FreeBSD as well? If the solution above doesn't work, you may have to get more closely engaged with the freebsd-java community or else consider trying another platform for the build.
We seem to have dodged this by using JDK5 to compile our GWT-based code. Not a perfect solution, but a work-around.