"Fatal Error" when loading a dll? - java

EDIT: I (sortof) figured this out. If I don't let my jar export the dlls, but instead manually put them in, it works fine. Now, my question is, how do I export the dlls CORRECTLY from inside my jar?
What is this? The reason I need to load some dlls is because I am using java3d, and I am trying to bundle it with the jar file instead of making people install it. Eclipse takes care of the jar files, but that leaves me to handle the dlls. Whenever I run my program, when a dll gets loaded, the whole jvm crashes. (Note that if I don't load the dlls, java 3d automatically tries system.loadLibrary())
Here is what comes out:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x772de9d7, pid=8044, tid=7616
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) Client VM (24.65-b04 mixed mode, sharing windows-x86)
# Problematic frame:
# C [ntdll.dll+0x3e9d7]
#
# Failed to write core dump. Minidumps are not enabled by default on client vers
ions of Windows
#
# An error report file with more information is saved as:
# C:\Users\bram.zerbe\Desktop\test\hs_err_pid8044.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.
#
Does anybody have any ideas?

Everything is all fixed up now, what I think was happening was that the byte[] that I was reading and writing with was bigger than needed, and didn't work. all fixed now

Related

Why does Java hang on my Mac when I try to use ImageIO?

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.

Libgdx 1.2.0 controllers extensions crash

I just recently updated to the newest Libgdx and set up my project with Gradle. Everything else seems to be working but I encountered a problem when attempting to add controller support to my game. When I attempt to get the controller or do anything with the Controller object the game crashes and presents this error.
Error creating joystick: Win32JoyStick::_initialize() >> failed to set cooperation level!
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000068904483, pid=2248, tid=716
#
# JRE version: Java(TM) SE Runtime Environment (8.0_11-b12) (build 1.8.0_11-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.11-b03 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [gdx-controllers-desktop64.dll+0x4483]
#
# 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\
#
# 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.
#
AL lib: (EE) alc_cleanup: 1 device not closed
I see all of the controller dependencies in the project folder for Android/Desktop and specified that I wanted to use the controller extension when setting up the Gradle project. I am using a PS3 controller and it works fine in other games.
Anyone have any ideas?
EDIT: Just tried with a PS2 controller and a USB adapter (not using the xbox360 drivers). Same issue with the crash.
Fixed by changing my DesktopLauncher class to not use my custom JFrame to display the game. You can see more information on why I changed this in the first place: https://stackoverflow.com/a/21731002/487578
This means I'll need to find an alternative way to solve my other problem..but I guess controller support is far more important than a small bug.

JavaFX EXCEPTION_ACCESS_VIOLATION

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.

Fatal error detected in Eclipse when using Xuggle

I was trying to get frames from a video using Xuggle 5.4. The IDE which I use is Eclipse Juno.The last time (which was roughly one months back) when I tried, I got the frames with a gap of 5 seconds, but today when I tried to run the code I got the below error
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006ee76520, pid=4340, tid=7344
#
# JRE version: 7.0_09-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [xuggle1062976990104623257.dll+0x736520] Java_com_xuggle_ferry_FerryJNI_SWIGRefCountedTesterUpcast+0x66f005
#
# 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:\Eclipse workspaces\Eclipse Juno\VideoSteganography\hs_err_pid4340.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.
#
When I googled this, I found similar similar problems, but i failed to get any solution or cause for this problem.
What may be the reason for this? I am not able to find the native code which is the cause for the crash. I used to update Java whenever available.
My need is to get the frames from a video file, what other ways are there to get this done? Feel free to ask for detail.
I had to switch to the 32Bit of JRE7 than it work again.
Problem was with Java7 updates. I just rolled back to Java6. Now it works fine for me now

A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb)

I am using RHEL 6 with 64 bit OS. For one of my application I had installed “jre-6u23-linux-x64.bin”. When I execute my application I am getting the below ERROR:
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x0000003222414d70, pid=4977, tid=140076581496592
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Problematic frame:**
# C [ld-linux-x86-64.so.2+0x14d70]
# An error report file with more information is saved as
# /root/Desktop/Madhu/SELVIEW10.0-B4/Linux/hs_err_pid4977.log
# 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.
Can anyone have solution for this?
Between
The crash happened outside the Java Virtual Machine in native code.
and
An error report file with more information is saved as
/root/Desktop/Madhu/SELVIEW10.0-B4/Linux/hs_err_pid4977.log
it looks like you're dealing with a defective native library. Have a look at that hs_err dump (it's plain text), it should point to the problem.
Another thing to try: the Compressed OOPS optimization was added to the JVM fairly recently, try disabling that (pass -XX:-UseCompressedOops on the command line) and see if the problem persists.
This issue is also discussed here: community.oracle.com thread
The suggested solution is to set LD_BIND_NOW=1:
export LD_BIND_NOW=1
$JAVA_HOME/bin/java -jar yourapp.jar

Categories

Resources