#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffce6d85c8b, pid=9324, tid=6592
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b15) (build 1.8.0_45-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [bulletjme.dll+0x15c8b]
#
# 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.
#
--------------- T H R E A D ---------------
Current thread (0x0000000034060000): JavaThread "jME3 Main" [_thread_in_native, id=6592, stack(0x0000000034ea0000,0x0000000034fa0000)]
siginfo: ExceptionCode=0xc0000005, writing address 0x0000000000000000
Registers:
RAX=0x0000000000000000, RBX=0x0000000035ed2580, RCX=0x0000000000000000, RDX=0x000000003a860c20
RSP=0x0000000034f9ea90, RBP=0x000000007a577020, RSI=0x000000003a860b68, RDI=0x000000003a859950
R8 =0x00000000ffffffff, R9 =0x0000000000000002, R10=0x0000000035ed2588, R11=0x0000000034f9e9f0
R12=0x0000000033c13f50, R13=0x000000003a860c20, R14=0x0000000000000000, R15=0x0000000000000000
RIP=0x00007ffce6d85c8b, EFLAGS=0x0000000000010207
Top of Stack: (sp=0x0000000034f9ea90)
0x0000000034f9ea90: 000000007a1a6b80 0000000000000000
0x0000000034f9eaa0: 0000000034f9edd8 0000000000000000
0x0000000034f9eab0: 000000003a860c20 000000003a859950
0x0000000034f9eac0: 0000000034f9edd8 000000003a860ad0
0x0000000034f9ead0: 0000000000000000 00007ffce6d86670
0x0000000034f9eae0: 0000000033c13f50 0000000000000002
0x0000000034f9eaf0: 000000003a860b68 0000000033c13f50
0x0000000034f9eb00: 0000000034f9eb50 0000000034f9eb58
0x0000000034f9eb10: 0000000034060000 00007ffce6df044a
0x0000000034f9eb20: 000000003b8fe550 0000000000000000
0x0000000034f9eb30: 0000000034060000 0000000034f9edd8
0x0000000034f9eb40: 000000003b8fe550 0000000000000000
0x0000000034f9eb50: 000000003a860ad0 000000003a860b68
0x0000000034f9eb60: 0000000000000002 00007ffce6e2a78b
0x0000000034f9eb70: 0000000033c13f50 00007ffce6f1ccc0
0x0000000034f9eb80: 0000000000000002 0000000034f9edd8
Instructions: (pc=0x00007ffce6d85c8b)
0x00007ffce6d85c6b: 74 0b 80 7b 58 00 74 05 e8 28 13 14 00 c6 43 58
0x00007ffce6d85c7b: 01 48 89 7b 50 89 73 48 48 63 4b 44 48 8b 43 50
0x00007ffce6d85c8b: 48 89 2c c8 ff 43 44 41 ff c6 49 83 c7 08 45 3b
0x00007ffce6d85c9b: 75 04 0f 8c dd fe ff ff 4c 8b 7c 24 20 48 8b 7c
Register to memory mapping:
RAX=0x0000000000000000 is an unknown value
RBX=0x0000000035ed2580 is an unknown value
RCX=0x0000000000000000 is an unknown value
RDX=0x000000003a860c20 is an unknown value
RSP=0x0000000034f9ea90 is pointing into the stack for thread: 0x0000000034060000
RBP=0x000000007a577020 is an unknown value
RSI=0x000000003a860b68 is an unknown value
RDI=0x000000003a859950 is an unknown value
R8 =0x00000000ffffffff is an unallocated location in the heap
R9 =0x0000000000000002 is an unknown value
R10=0x0000000035ed2588 is an unknown value
R11=0x0000000034f9e9f0 is pointing into the stack for thread: 0x0000000034060000
R12=0x0000000033c13f50 is an unknown value
R13=0x000000003a860c20 is an unknown value
R14=0x0000000000000000 is an unknown value
R15=0x0000000000000000 is an unknown value
Stack: [0x0000000034ea0000,0x0000000034fa0000], sp=0x0000000034f9ea90, free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [bulletjme.dll+0x15c8b]
C [System.Xml.ni.dll+0x16670]
C [bulletjme.dll+0xba78b]
C [CRYPTBASE.dll+0x8345]
C [bulletjme.dll+0x9f1f]
C [bulletjme.dll+0xba8cb]
C [bulletjme.dll+0x1622ee]
C 0x0000000002a85e34
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.jme3.bullet.PhysicsSpace.stepSimulation(JFIFZZZ)V+0
j com.jme3.bullet.PhysicsSpace.update(FIZZZ)V+94
j com.jme3.bullet.PhysicsSpace.update(FI)V+124
j com.jme3.bullet.PhysicsSpace.update(F)V+76
j com.jme3.bullet.BulletAppState.render(Lcom/jme3/renderer/RenderManager;)V+72
J 3034 C1 com.jme3.app.state.AppStateManager.render(Lcom/jme3/renderer/RenderManager;)V (93 bytes) @ 0x00000000034893ac [0x0000000003488900+0xaac]
j com.jme3.app.SimpleApplication.update()V+161
j com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop()V+22
j com.jme3.system.lwjgl.LwjglDisplay.runLoop()V+145
j com.jme3.system.lwjgl.LwjglAbstractDisplay.run()V+136
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
This is the id for the problematic frame from a native code perspective as denoted by C.
This is your current thread id, followed by the registers and the problematic stack dump…
This is the register address pointing to your thread, its the top of the problematic stack, ‘sp’ for stack pointer, the top of the stack/memory.
And finally, this is the code dump for the ‘sp’ showing the problematic frame ‘C [bulletjme.dll+0x15c8b]’ code which seems to be parallel to the java method com.jme3.bullet.PhysicsSpace.stepSimulation(JFIFZZZ)V, so long story short check your code if it were using something that calls stepSimulation() that causes this problematic frame.
It looks like Minie issue, since PhysicsSpace.update i belive is directly related, and since it refer to bulletjme.dll that exist and was probably “added” by Minie.
There is also possibility that you use 2 physics libs that cause issue.
Anyway i belive its worth notify @sgold that might know reason
Yeah something goes wrong with the native code controlling the physics library update, i was getting some exceptions similar to these (in C generally) which refers to a Segmentation fault causes memory access violations, if you delete a pointer (or a thread deletes it apparently) and another thread tries to reuse it again.
The exception disappeared when I switched from Minie:5.0.0+mt to Minie:5.0.0
Now the app works fine on Windows but not as expected on Android. I will do some more tests and report
Not working as expected on Android was my code issue. for now, switching to Minie 5.0.0 solved the Windows problem in the cost of an extra ~10MB of installation size - reasonable limitation
The “Mt” versions of Libbulletjme use lightweight worker threads (created using OpenMP) to parallelize certain loops involved in stepping a PhysicsSpace. For applications with a single PhysicsSpace, I believe they are thread-safe.
The “Mt” option is intended to boost performance on multi-threaded CPUs. For the workload I tested, the performance gains were moderate, and they topped out at 2 threads, perhaps due to limited memory bandwidth. (It didn’t help that significant portions of the Bullet algorithm are inherently serial.) Due to incompatibility between Xcode and OpenMP, I haven’t got “Mt” working for MacOS.
so it looks like multithread related, but idk why it would not work for Windows.
Anyway i belive its worth notify @sgold that might know reason
Unfortunately, the information in the JVM crash-log excerpt doesn’t tell me much about the root cause of the crash. I can see that the crash occurred while stepping the physics simulation, and that’s about it. I know the crash occurred at bulletjme.dll+0x15c8b, but I don’t know where that is in the source code. There are perhaps thousands of ways to crash Minie that would result in a similar-looking crash log.
To debug a JVM crash involving Minie, the first step would be to reproduce the crash using a debug build of Minie such as com.github.stephengold:Minie:5.0.0+debug. For this and other debugging advice, please see Troubleshooting physics issues :: The Minie project
Now the app works fine on Windows but not as expected on Android.
If you plan to run your app on Android, you should definitely avoid com.github.stephengold:Minie:5.0.0+mt because that version is only for (64-bit) Linux and Windows—it doesn’t include any Android native libraries.
