Closed stephengold closed 5 months ago
The crash occurs while loading a collision shape using Libbulletjme v21.0.0 that was saved using that same native library on the same platform.
The crash occurs during the 2nd invocation of MeshCollisionShape.read()
.
Excerpt from MeshCollisionShape.createShape()
:
boolean buildBvh = false;
long meshId = nativeMesh.nativeId();
long shapeId = createShape(useCompression, buildBvh, meshId);
setNativeId(shapeId);
setContactFilterEnabled(enableContactFilter);
setScale(scale); // <----- crash occurs here!
Just before the crash, the value of scale
is (16.336132, 1, 5.044612).
When btTriangleMeshShape::setLocalScaling()
is invoked, m_bvh == NULL
.
btTriangleMeshShape::setLocalScaling()
must re-calculate the shape's AABB.
The recalculation invokes btTriangleMeshShape::localGetSupportingVertex()
, which invokes
btBvhTriangleMeshShape::processAllTriangles()
.
Line 326 of processAllTriangles()
dereferences m_bvh
, which is still NULL
. That's what crashes the JVM.
It ought to be possible to iterate over all mesh triangles without using BVH, but that's not how btBvhTriangleMeshShape
is written.
I added a test app to Minie: https://github.com/stephengold/Minie/commit/3802942718403ba209967d708d1b30701eb037b8
The fix is in: dcb979dd
joliver82 has confirmed the fix on Linux and Windows.
Prior discussion: https://hub.jmonkeyengine.org/t/jvm-crash-in-stranded/47354/27
I reproduced the crash on Linux using DebugSp natives and the "pc-screen.gltf" model. Here is a native stack trace from GDB:
And here's the Java stack from the crash log: