[Solved] Issues with native bullet in 3.1 branch

Troubleshooting physics
1

I’m having issues with native bullet since it was changed to use gradle 2.13. Before the commit

I could build the native library just fine using the task windows_x86_64BulletjmeSharedLibrary and I wasn’t seeing any issues when using it. However from that commit and on, I have to get rid of the “buildable” check in order for the dll to build. Otherwise it tells me it can’t find jni.h for some reason. If I get rid of the check and build it using bulletjmeWindows64SharedLibrary it builds fine and everything seems to work. I’m wondering what that check is for exactly, since if it actually couldn’t find JNI, physics wouldn’t work at all.

Also another problem I’ve come across recently is when I try to load a j3o file and enabling debug mode for the physics, I get a native crash with the following log:

Register to memory mapping:

RAX=0x0000000000000000 is an unknown value
RBX=0x0000000021fcb410 is an unknown value
RCX=0x0000000000000000 is an unknown value
RDX=0x000000002527eaa0 is pointing into the stack for thread: 0x0000000023245800
RSP=0x000000002527ea20 is pointing into the stack for thread: 0x0000000023245800
RBP=0x000000002527ea70 is pointing into the stack for thread: 0x0000000023245800
RSI=0x0000000010227000 is an unknown value
RDI=0x000000000015c530 is an unknown value
R8 =0x000000002527eb80 is pointing into the stack for thread: 0x0000000023245800
R9 =0x000000002527eb70 is pointing into the stack for thread: 0x0000000023245800
R10=0x0000000000000000 is an unknown value
R11=0x000000002527e810 is pointing into the stack for thread: 0x0000000023245800
R12=0x0000000000000000 is an unknown value
R13={method} {0x0000000024b32418} 'getVertices' '(JLcom/jme3/bullet/util/DebugMeshCallback;)V' in 'com/jme3/bullet/util/DebugShapeFactory'
R14=0x000000002527ed00 is pointing into the stack for thread: 0x0000000023245800
R15=0x0000000023245800 is a thread


Stack: [0x0000000025180000,0x0000000025280000],  sp=0x000000002527ea20,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [bulletjme.dll+0x6c3c0]
C  [bulletjme.dll+0x668cb]
C  [bulletjme.dll+0xb4137]
C  0x0000000004485e34

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.jme3.bullet.util.DebugShapeFactory.getVertices(JLcom/jme3/bullet/util/DebugMeshCallback;)V+0
j  com.jme3.bullet.util.DebugShapeFactory.getDebugMesh(Lcom/jme3/bullet/collision/shapes/CollisionShape;)Lcom/jme3/scene/Mesh;+29
j  com.jme3.bullet.util.DebugShapeFactory.createDebugShape(Lcom/jme3/bullet/collision/shapes/CollisionShape;)Lcom/jme3/scene/Geometry;+10
j  com.jme3.bullet.util.DebugShapeFactory.getDebugShape(Lcom/jme3/bullet/collision/shapes/CollisionShape;)Lcom/jme3/scene/Spatial;+154
j  com.jme3.bullet.debug.BulletRigidBodyDebugControl.<init>(Lcom/jme3/bullet/debug/BulletDebugAppState;Lcom/jme3/bullet/objects/PhysicsRigidBody;)V+45
j  com.jme3.bullet.debug.BulletDebugAppState.updateRigidBodies()V+148
j  com.jme3.bullet.debug.BulletDebugAppState.update(F)V+6
j  com.jme3.app.state.AppStateManager.update(F)V+48
j  com.jme3.app.SimpleApplication.update()V+77
j  com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop()V+22
j  com.jme3.system.lwjgl.LwjglDisplay.runLoop()V+104
j  com.jme3.system.lwjgl.LwjglAbstractDisplay.run()V+136
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

This is the test case that generated the log:

package test;

import com.jme3.app.SimpleApplication;
import com.jme3.bullet.BulletAppState;
import com.jme3.scene.Node;

public class BulletDebugTest extends SimpleApplication{
    
    public static void main(String[] args){
        new BulletDebugTest().start();
    }
    
    @Override
    public void simpleInitApp(){
        BulletAppState bulletAppState = new BulletAppState();
        getStateManager().attach(bulletAppState);
        bulletAppState.setDebugEnabled(true);
        
        Node node = (Node) assetManager.loadModel("TheFile.j3o");
        bulletAppState.getPhysicsSpace().addAll(node);
    }
}

I’m not sure exactly whats going on here. Everything was fine before the switch to gradle 2.13, so I’m not sure exactly what changed to cause these problems.

@Momoko_Fan, do you have any ideas since you made the commits?

If you would like the j3o that I used I can give it to you.

2

Finally figured out the issue to this problem. The issue we’re these lines in the build.gradle.

    toolChains {
        gcc(Gcc)
	clang(Clang)
        mingw_x86(Gcc) {
            eachPlatform() {
                cCompiler.executable "i686-w64-mingw32-gcc"
                cppCompiler.executable "i686-w64-mingw32-g++"
                linker.executable "i686-w64-mingw32-g++"
                assembler.executable "i686-w64-mingw32-g++"
                staticLibArchiver.executable "i686-w64-mingw32-gcc-ar"
            }
            target("Windows32")
        }
        mingw_x86_64(Gcc) {
            eachPlatform() {
                cCompiler.executable "x86_64-w64-mingw32-gcc"
                cppCompiler.executable "x86_64-w64-mingw32-g++"
                linker.executable "x86_64-w64-mingw32-g++"
                assembler.executable "x86_64-w64-mingw32-g++"
                staticLibArchiver.executable "x86_64-w64-mingw32-gcc-ar"
            }
            target("Windows64")
        }
    }

Not sure why, but specifying the tool chains for windows seems to corrupt the compiled dll or something. If I remove this I no longer get unexpected crashes like the one above. It may be something to do with how my environment is setup? I don’t know, I’m not to knowledgeable when it comes to this.

1 Like