Tracking down a crash in bullet native

Hey guys,

I occasionally get this crash when using bullet-native:

[java] # JRE version: 7.0_21-b02
# Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libbulletjme64.so+0xc9e70] btDbvtBroadphase::setAabb(btBroadphaseProxy*, btVector3 const&, btVector3 const&, btDispatcher*)+0x20[/java]

I tried to use AXIS_SWEEP_3 like so:

[java] GPhysicsAppState = new BulletAppState(new Vector3f(-Positioner.MAX_RESET_DIST - 256f,
-2000f,
-Positioner.MAX_RESET_DIST - 256f),
new Vector3f(Positioner.MAX_RESET_DIST + 256f,
2000f,
Positioner.MAX_RESET_DIST + 256f), PhysicsSpace.BroadphaseType.AXIS_SWEEP_3);[/java]

… and I do see this in jmePhysicsSpace.cpp:

[java] switch (broadphaseId) {
case 0:
broadphase = new btSimpleBroadphase();
break;
case 1:
broadphase = new btAxisSweep3(min, max);
break;
case 2:
//TODO: 32bit!
broadphase = new btAxisSweep3(min, max);
break;
case 3:
broadphase = new btDbvtBroadphase();
break;
case 4:
// broadphase = new btGpu3DGridBroadphase(
// min, max,
// 20, 20, 20,
// 10000, 1000, 25);
break;
}
[/java]

… which makes it appear the broadphase setting should be set. However, I still see that crash occasionally.

So, I guess my questions are, shouldn’t btDbvtBroadphase::setAabb not be called if I am using AXIS_SWEEP_3? Is this broadphase mode not getting set correctly? Also, any tips on trying to fix this bug, which I’m hoping to do?

Thanks!

Native bullet is only really tested with DVBT, why do you want to use AxisSweep anyway? Its inferior in almost all respects.

According to the wiki @ http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Broadphase, it says:

“This broadphase has the best performance for typical dynamics worlds, where most objects have little or no motion.”, which accurately describes my world. I also tried to use it to see if it would work around the btDbvtBroadphase::setAabb crash. However, it looks like either btDbvtBroadphase::setAabb still gets called in AxisSweep or AxisSweep isn’t being used for some reason… at any rate, I’d like to fix this or find a workaround.

1 Like

Cool, keep us updated.

Looks like my native build process broke again… gets stuck in an infinite loop:

[java]-compile-bullet-sources-linux-64:
[exec] INTEL OPENCL NOT FOUND
[exec] NVidia OPENCL NOT FOUND
[exec] – Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
[exec] – Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
[exec] – Looking for gethostbyname
[exec] – Looking for gethostbyname - found
[exec] – Looking for connect
[exec] – Looking for connect - found
[exec] – Looking for remove
[exec] – Looking for remove - found
[exec] – Looking for shmat
[exec] – Looking for shmat - found
[exec] – Looking for IceConnectionNumber in ICE
[exec] – Looking for IceConnectionNumber in ICE - found
[exec] – Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
[exec] OPENGL FOUND
[exec] /usr/lib/x86_64-linux-gnu/libGLU.so/usr/lib/x86_64-linux-gnu/libGL.so/usr/lib/x86_64-linux-gnu/libSM.so/usr/lib/x86_64-linux-gnu/libICE.so/usr/lib/x86_64-linux-gnu/libX11.so/usr/lib/x86_64-linux-gnu/libXext.so
[exec] GLUT FOUND
[exec] /usr/lib/x86_64-linux-gnu/libglut.so
[exec] You have changed variables that require your cache to be deleted.
[exec] Configure will be re-run and you may have to reset some variables.
[exec] The following variables have changed:
[exec] CMAKE_C_COMPILER= gcc
[exec] CMAKE_CXX_COMPILER= g++
[exec]
[exec] INTEL OPENCL NOT FOUND
[exec] NVidia OPENCL NOT FOUND
[exec] – Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so
[exec] – WARNING: you are using the obsolete ‘GLU’ package, please use ‘OpenGL’ instead
[exec] – Found GLUT: /usr/lib/x86_64-linux-gnu/libglut.so
[exec] – WARNING: you are using the obsolete ‘GLU’ package, please use ‘OpenGL’ instead
[exec] – Configuring done
[exec] – Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
[exec] – Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
[exec] – Looking for gethostbyname
[exec] – Looking for gethostbyname - found
[exec] – Looking for connect
[exec] – Looking for connect - found
[exec] – Looking for remove
[exec] – Looking for remove - found
[exec] – Looking for shmat
[exec] – Looking for shmat - found
[exec] – Looking for IceConnectionNumber in ICE
[exec] OPENGL FOUND
[exec] /usr/lib/x86_64-linux-gnu/libGLU.so/usr/lib/x86_64-linux-gnu/libGL.so/usr/lib/x86_64-linux-gnu/libSM.so/usr/lib/x86_64-linux-gnu/libICE.so/usr/lib/x86_64-linux-gnu/libX11.so/usr/lib/x86_64-linux-gnu/libXext.so
[exec] GLUT FOUND
[exec] /usr/lib/x86_64-linux-gnu/libglut.so
[exec] You have changed variables that require your cache to be deleted.
[exec] Configure will be re-run and you may have to reset some variables.
[exec] The following variables have changed:
[exec] CMAKE_C_COMPILER= gcc
[exec] CMAKE_CXX_COMPILER= g++
[exec]
[exec] – Looking for IceConnectionNumber in ICE - found

[/java]

I assume I need to run this if I make changes to jmePhysicsSystem.cpp etc. in engine/src/bullet-native ?

What “this”? You need to build the binary again if you change the source code, yes.

I upgraded to CMake v2.8.11-rc3 & the looping problem went away! Now I have to retrace my steps to get this to build properly again…

EDIT: Yay, got it building again! Now I might be able to do some debugging here…

Found the bug! It was actually a TODO item in PhysicsSpace.java:

[java] public void create() {
// TODO: broadphase!
physicsSpaceId = createPhysicsSpace(worldMin.x, worldMin.y, worldMin.z, worldMax.x, worldMax.y, worldMax.z, 3, false);[/java]

Changed to:

[java] public void create() {
physicsSpaceId = createPhysicsSpace(worldMin.x, worldMin.y, worldMin.z, worldMax.x, worldMax.y, worldMax.z, broadphaseType.ordinal(), false);[/java]

Which fixes the problem in selecting the broadphase type. If there are no objections, I’m going to push this change…

Sure but this only makes sense to put in binary form if all binaries (incl. osx) get updated, else just commit the code please.
Edit: Oh wait, its just java code right? So just commit that, it will go to the build w/o the binaries being rebuilt.

Yup, no change was needed to the bullet binaries (phew!)

I just want to report I have experienced no crashes when using AxisSweep & I haven’t really noticed any differences in performance (e.g. both are sufficiently fast).

2 Likes