Lately whenever I run my OpenGL game I get this strange error:
I am on OS X.
What does this error mean?
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00000001276eff9f, pid=461, tid=5379
#
# 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 bsd-amd64 compressed oops)
# Problematic frame:
# C [GLEngine+0x15bf9f] gleRunVertexSubmitImmediate+0x27ef
#
# 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/amit/workspace/Evox Voxel Engine GL 2.1/hs_err_pid461.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.
#
This error is generated whenever I draw:
GL11.glDrawElements(GL11.GL_TRIANGLES, indicesCount,
GL11.GL_UNSIGNED_INT, 0);
This was my problem:
I was using a global Indices VBO for all chunks because I figured it wouldn't matter if I draw a bit more indices than I would actually have. Turns out this causes some kind of buffer overflow or reading/writing to an invalid address that causes the entire game to crash.
So the lesson is always calculate EXACTLY the amount of indices that you have for EACH object and then supply that to the draw method, otherwise it could cause weird behaviour.
Also another possible problem would be that your indices VBO is limited by the type of it, for example byte/short/int. This could cause your game to crash if your indices go over the amount that a byte/short/int can hold.
Happy programming.
Related
I have a Java server process that is now intermittently crashing with the following crash report:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8c169f6df8, pid=33597, tid=140237357057792
#
# JRE version: Java(TM) SE Runtime Environment (8.0_40-b25) (build 1.8.0_40-b25)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x404df8] PhaseChaitin::gather_lrg_masks(bool)+0x208
#
# 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:
# / blah2/hs_err_pid33597.log
#
# Compiler replay data is saved as:
# /blah2/replay_pid33597.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Before I think of effecting any machine configuration changes (such as changing the VM flags passed in or adding additional logging of any kind), I would like to perform as much analysis of whatever diagnostic information is available.
Does the replay_pid file have information that can help me (as an application developer) diagnose this problem or is it for VM crash reporting to Oracle? Are there any tools available that can analyze it (similar to a thread dump analyzer for instance)?
Any help/hints appreciated.
Thanks
AD
Yes, the replay file can help you to reproduce the issue in a controlled manner.
There's an excellent presentation "Analyzing HotSpot Crashes" by Volker Simonis which covers this - here's a direct link to the relevant example in that talk: https://www.youtube.com/watch?v=xC8fEeo7izI&feature=youtu.be&t=1888
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 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.
My JRE crashed when executing a shared library function called from java code via JNI. The output says that JRE crashed because it "Failed to write core dump. Core dumps have been disabled.".
After many days googling without explanation, my questions is:
Where can I find info about JRE core dumping? I want to understand the problem and the solution.
I know the output recommends executing "ulimit -c unlimited" and this questions proposes solutions (How to enable program to dump core on linux?)
Here I've pasted the JRE output:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f7e541cec55, pid=20390, tid=140180586714880
#
# JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libXXX.so+0x1fc55] NewMask_UnsetAll+0x15
#
# 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:
# /XXX/hs_err_pid20390.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
I know this is an old question…
This message "Failed to write core dump. Core dumps have been disabled." didn't mean this was the cause of the crash. The word "Failed" is indeed misleading here.
This message only means that core dumps are disabled in the Java VM (which is usually the case), so that such dumps are not produced in case of crash.
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