[SOLVED] Crash Error using more than one DynamicAnimControl

User Code & Projects Minie
1

I am working on implementing ragdoll physics to my game, and am running into trouble trying to get the DynamicAnimControl to work when I have more than 1 DAC controlled model in the scene. (Also having a similar crash with one specific model even when its the only one, but only sometimes so I can’t reproduce it as easily).

Here is the output right before the game crashes, immediately after I call setRagDolMode() on the second DAC controlled model in the scene. (first it gives me this series of warnings that only occurr prior to the crash)

May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
May 10, 2022 10:24:14 PM com.jme3.bullet.objects.PhysicsRigidBody setGravity
WARNING: The body is not in any PhysicsSpace.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff96b2541fc, pid=14860, tid=12420
#
# JRE version: OpenJDK Runtime Environment (11.0.6+10) (build 11.0.6+10)
# Java VM: OpenJDK 64-Bit Server VM (11.0.6+10, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  [bulletjme.dll+0x41fc]
#
# 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\ryan\Desktop\JM\TheAfflictedForests\hs_err_pid14860.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/AdoptOpenJDK/openjdk-support/issues
# 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

> Task :run FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':run'.
> Process 'command 'C:\Program Files\jmonkeyplatform\jdk\bin\java.exe'' finished with non-zero exit value 1

And here is what is written to the hs_err_pid14860.log referenced in the above crash error: ( i shortened it because it was way over the character limit for a forum post and including a lot of memory location info I assume isn’t necessary, but I think I included the important part; let me know if I need to include more)

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff96b2541fc, pid=14860, tid=12420
#
# JRE version: OpenJDK Runtime Environment (11.0.6+10) (build 11.0.6+10)
# Java VM: OpenJDK 64-Bit Server VM (11.0.6+10, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  [bulletjme.dll+0x41fc]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   https://github.com/AdoptOpenJDK/openjdk-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  S U M M A R Y ------------

Command Line: -Djava.library.path=libs -Dfile.encoding=windows-1252 -Duser.country=US -Duser.language=en -Duser.variant com.theafflictedforests.MainSA.Main

Host: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz, 8 cores, 15G,  Windows 10 , 64 bit Build 19041 (10.0.19041.1645)
Time: Tue May 10 22:24:14 2022 Eastern Daylight Time elapsed time: 33 seconds (0d 0h 0m 33s)

---------------  T H R E A D  ---------------

Current thread (0x0000019cdf599000):  JavaThread "jME3 Main" [_thread_in_native, id=12420, stack(0x00000059cb100000,0x00000059cb200000)]

Stack: [0x00000059cb100000,0x00000059cb200000],  sp=0x00000059cb1fe860,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [bulletjme.dll+0x41fc]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 5449  com.jme3.bullet.PhysicsSpace.stepSimulation(JFIFZZZ)V (0 bytes) @ 0x0000019cc882edb2 [0x0000019cc882ed40+0x0000000000000072]
J 5448 c1 com.jme3.bullet.PhysicsSpace.update(FIZZZ)V (96 bytes) @ 0x0000019cc19dab5c [0x0000019cc19da9e0+0x000000000000017c]
J 5447 c1 com.jme3.bullet.PhysicsSpace.update(FI)V (126 bytes) @ 0x0000019cc19da524 [0x0000019cc19da0a0+0x0000000000000484]
J 4456 c1 com.jme3.bullet.PhysicsSpace.update(F)V (79 bytes) @ 0x0000019cc174f6f4 [0x0000019cc174f5e0+0x0000000000000114]
J 4455 c1 com.jme3.bullet.BulletAppState.render(Lcom/jme3/renderer/RenderManager;)V (76 bytes) @ 0x0000019cc174f08c [0x0000019cc174ee00+0x000000000000028c]
J 6525 c2 com.jme3.app.state.AppStateManager.render(Lcom/jme3/renderer/RenderManager;)V (93 bytes) @ 0x0000019cc8a372ec [0x0000019cc8a37160+0x000000000000018c]
J 5620 c1 com.jme3.app.SimpleApplication.update()V (235 bytes) @ 0x0000019cc1a52824 [0x0000019cc1a51fe0+0x0000000000000844]
J 5619 c1 com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop()V (141 bytes) @ 0x0000019cc1a51174 [0x0000019cc1a50f80+0x00000000000001f4]
J 5614 c1 com.jme3.system.lwjgl.LwjglDisplay.runLoop()V (149 bytes) @ 0x0000019cc1a4c25c [0x0000019cc1a49e00+0x000000000000245c]
j  com.jme3.system.lwjgl.LwjglAbstractDisplay.run()V+136
j  java.lang.Thread.run()V+11 java.base@11.0.6
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000019bc2375eb0


Register to memory mapping:

The crash and the setGravity warnings do not occur when I load a single DAC model into my game. I am working with a Fox, Bear, and Elf model right now, and both the Fox and Bear work perfectly when they are loaded in 1 at a time. But as soon as I load in a second one and call setRagDollMod() on it, the crash occurs.

I also get inconsistent crashes with the wood elf model. When it is used for the player’s character model, it crashes nearly every time even when loaded on its own, and other times it will take a while before the crash occurs if I spawn in a second wood elf before setting myself into ragdoll mode. Also, when I use a dark skinned version of the same model that is loaded from a separate .j3o (but has same animation rig so the same DAC code works), then it works just like the Bear and Fox where everything works until a second model is set to ragdoll mode.

1 Like
2

It seems like you may be encountering several issues. Unfortunately, none of the symptoms you report is familiar to me. With the circumstances and descriptions interleaved into a single post, it’s hard for me to make sense of it all.

It’s not unusual to have multiple ragdolls in a single application. I’ve done so many times. It doesn’t suggest to me what the root cause(s) of the issue(s) you’re seeing might be.

The warning messages are unusual. I haven’t seen them before in connection with DAC. They occur at a low level. It might help to see the complete call stack at the time a log message is generated. Could you set a breakpoint on the logger invocation, or build a local copy of Minie that replaces the logger with an exception?

The crash log is very generic. The crash occurred while the simulation was being stepped, but the log gives me no clue why. If you reproduce the crash using a debug native library, the resulting crash log might provide a more complete stack trace. Or the app might fail sooner, giving more clues as to what’s causing the issue. See the debugging page in the Minie tutorial for this and other debugging tricks.

Our best hope for solving the issue(s) you’re seeing would be to boil the game down into the simplest app that reproduces it/them. Write a simple test app that reproduces one or more of the issues, using free models—something I can tinker with. For a complex game like The Afflicted Forest, I don’t imagine this will be easy, but—it’s our best hope.

1 Like
3

After sleeping on this topic, I’ve convinced myself that the “not in any PhysicsSpace” warnings are harmless. You can ignore them, and I’ll take steps to prevent DAC from generating the warnings in future releases.

I still want to understand the root cause of the JRE crashes. If you learn anything more about them, let me know.

2 Likes
4

I will work on this and report back as soon as I get the full stack trace with more info.

I will also work on setting up a test case as soon as I can. I will use a copy of the wood elf model I’m having trouble with, since that was made with makehuman and is free.

1 Like
5

I made a test case with the elf model and tried to complicate the setup with the animations as much as possible to match the state my game is in, but still could not reproduce the error in the test case.

I also tried removing some complex parts from my game, such as the water or shadows, and also tried loading things up on a tiny map with only a single terrain, yet I still get the error in my game, even when nothing else is added to the physics space but 2 DACs and the terrain. So unfortunately I’m not sure the test case helped narrow anything down so far.

Do you think you could give me some additional insight on how to do this? I’m not sure if I’m understanding where I should put the breakpoint, or what part of the Minie code I should replace the logger with an exception to find out more.

My initial thought was that you meant to put a break point right before this line that calls stepSimulation(), or surround it with try/catch, but I think I might be misunderstanding what you mean since I’m unfamiliar with debugging a complicated crash error like this that isn’t easily solved based on the console output like I’m used to.

6

We already have the Java stack at the time of a stepSimulation() crash.

I was requesting a stack trace at the time of a “not in any PhysicsSpace” warning. But since I became convinced those warnings are harmless, that request is no longer a priority. I suggest you focus on reproducing the crash in a simple test.

1 Like
7

I will keep working on it and report back if I find anymore results testing out different things. But I am also open to any suggestions if you (or anyone) have any ideas where to look or what to test.

On top of adding things to the test case, I also tried adding the simple code from my test case into my game, and it looks like I can get many elf models working in ragdoll mode within my game when I spawn it in without using the game related AI and Agent code I typically use to setup an advanced Agent.

So I also tried to comment out the entirety of the code in my agent’s update loop so nothing gets called from there at all, and I also commented out all of the initiation for everything related to a new agent spawning in, except for the code in the animation state that sets up a DAC - and the issue still occurs.

So for now I am stumped and unfortunately feel defeated, but will keep thinking about it and hopefully solve it in time. But for now I don’t know what else to try since the test case works in my game even with the whole world loaded and running, and I also cannot reproduce the crash when I simplify my agent update and initiation code to be the same as the test case.

1 Like
8

An EXCEPTION_ACCESS_VIOLATION in PhysicsSpace.stepSimulation() doesn’t provide much of a clue.

I assume you’ve already tried testing Afflicted Forest with assertions enabled—if not, that might catch the issue sooner.

It should be possible to obtain a native stack trace by re-generating the crash log using an app built with a debug version of Minie such as “Minie-4.9.0+debug”. This is easy on Linux, since Linux stores the symbol table in the native library. Windows doesn’t, so it’s a little harder there.

Since you seem to be testing on Windows, here are some details … In addition to rebuilding with “Minie-4.9.0+debug”, you’d need to download and install the corresponding PDB file from GitHub before running the test. For single-precision, single-threaded v4.9.0 on 64-bit Windows, the correct PDB would be https://github.com/stephengold/Libbulletjme/releases/download/14.3.0/Windows64DebugSp_bulletjme.pdb.

I haven’t actually used a PDB file in a long time. I believe the PDB file ought to be stored in the folder where the application will run, but I might be wrong about that.

Edit: I also encourage you to open an issue at GitHub where you can archive the complete crash log and any other information about this issue.

1 Like
9

I did not actually, I completely forgot about you mentioning that when I got carried away trying a bunch of different things with the test case.

I enabled assertions for the afflicted forests and am now getting this error at the same time the previous crash would occur

java.lang.AssertionError: true
	at com.jme3.bullet.objects.PhysicsRigidBody.isKinematic(PhysicsRigidBody.java:615)
	at com.jme3.bullet.PhysicsSpace.addRigidBody(PhysicsSpace.java:1315)
	at com.jme3.bullet.PhysicsSpace.addCollisionObject(PhysicsSpace.java:1049)
	at com.jme3.bullet.objects.PhysicsRigidBody.rebuildRigidBody(PhysicsRigidBody.java:1133)
	at com.jme3.bullet.objects.PhysicsRigidBody.cloneFields(PhysicsRigidBody.java:1151)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:269)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.bullet.joints.PhysicsJoint.cloneFields(PhysicsJoint.java:276)
	at com.jme3.bullet.joints.Constraint.cloneFields(Constraint.java:481)
	at com.jme3.bullet.joints.SixDofJoint.cloneFields(SixDofJoint.java:496)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:269)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.bullet.animation.PhysicsLink.cloneFields(PhysicsLink.java:673)
	at com.jme3.bullet.animation.BoneLink.cloneFields(BoneLink.java:472)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:269)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:68)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:43)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:242)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.bullet.animation.PhysicsLink.cloneFields(PhysicsLink.java:672)
	at com.jme3.bullet.animation.BoneLink.cloneFields(BoneLink.java:472)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:269)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:68)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:43)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:242)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.bullet.animation.PhysicsLink.cloneFields(PhysicsLink.java:672)
	at com.jme3.bullet.animation.BoneLink.cloneFields(BoneLink.java:472)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:269)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:68)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:43)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:242)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.bullet.animation.DacLinks.cloneFields(DacLinks.java:721)
	at com.jme3.bullet.animation.DynamicAnimControl.cloneFields(DynamicAnimControl.java:904)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:269)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:68)
	at com.jme3.util.clone.ListCloneFunction.cloneFields(ListCloneFunction.java:43)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:242)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.scene.Spatial.cloneFields(Spatial.java:1482)
	at com.jme3.scene.Node.cloneFields(Node.java:744)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:269)
	at com.jme3.util.clone.Cloner.clone(Cloner.java:168)
	at com.jme3.scene.Spatial.clone(Spatial.java:1392)
	at com.jme3.scene.Node.clone(Node.java:703)
	at com.jme3.scene.Node.clone(Node.java:60)
	at com.jme3.scene.Spatial.clone(Spatial.java:1425)
	at com.theafflictedforests.CoreAppClasses.Interface.HUD_Components.CustomizableComponents.StatusFrames.FramePicture.attachCharacterFaceToFrame(FramePicture.java:158)
	at com.theafflictedforests.CoreAppClasses.Interface.HUD_Components.CustomizableComponents.StatusFrame.setAgent(StatusFrame.java:187)
	at com.theafflictedforests.CoreAppClasses.Interface.HUD_Components.CustomizableComponents.StatusFrames.TargetStatusFrame.setAgent(TargetStatusFrame.java:173)
	at com.theafflictedforests.CoreAppClasses.Interface.HUDInterface.update(HUDInterface.java:516)
	at com.jme3.app.state.AppStateManager.update(AppStateManager.java:371)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:258)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:160)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:201)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:242)
	at java.base/java.lang.Thread.run(Thread.java:834)

Edit: I tried adding a call to dynamicAnimControl.setKineamticMode() before setting it in ragDoll mode, and the assertion error has gone away, but now its crashing with the same EXCEPTION_ACCESS_VIOLATION again when a second one gets added. So I think this assertion error I got may have been unrelated.

1 Like
10

Nevermind I was wrong about this, the assertion error still happens. I tricked myself into thinking the assertion error went away because I accidentally disabled assertions in my game’s gradle build file thinking it was the test case’s build file at one point, my bad.

However I double checked that assertions enabled in both now, and the assertion error consistently occurs in my game, but does not occur in the test case. So it seems like the assertion error could be relevant to solving the issue.

1 Like
11

Physics objects should never be cloned while added to a PhysicsSpace.

From the stack trace, it appears that there’s a DynamicAnimControl that’s been added to a space and a spatial, and an ancestor Node is getting cloned by FramePicture for some reason.

2 Likes
12

I got rid of the clone call and that fixed the issue. I thought I had disabled that FramePicture class recently after I upgraded to the new animation system because it was still trying to use the controls from the old system, so I just commented out a bunch of code and was going to go back to update it after figuring out everything with the new system.

And apparently I did not comment out the cloning of the spatial, I just commented out the part where it gets attached to the scene which made me think it was fully disabled when it technically wasn’t, another mistake on my part.

I appreciate the help solving this issue, I feel like I made it more difficult than necessary tripping over my own feet while trying to debug and troubleshoot everything, but I’m glad it ended up being an easy fix in the end. Thanks so much :slightly_smiling_face: I’m excited to finally get to work on making a more realistic combat system for my game with realistic ragdoll and knockback physics. Minie is most certainly an impressive and powerful physics library.

1 Like
13

I’m glad the problem’s solved and only slightly disappointed there wasn’t an actual Minie issue for me to debug.

You can repay me with cool videos in the monthly screenshot thread.

Onward!

4 Likes