crash in PhysicsSpace.finalizeNative()

[stephengold]

How to reproduce: build current the 3.3.1 release candidate (commit= a150deb ) and run the TestChooser app. Select "TestQ3", "run", escape, "run", escape, and "run" again. On my Mint Linux machine, the JVM crashes immediately during the 3rd run, with the following stack trace:

Stack: [0x00007f424fcfd000,0x00007f424fdfe000],  sp=0x00007f424fdfc758,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libbulletjme.so+0x47a130]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.jme3.bullet.PhysicsSpace.finalizeNative(J)V+0
j  com.jme3.bullet.PhysicsSpace.finalize()V+34
J 1324 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007f4261447ec4 [0x00007f4261447940+0x584]
J 1323 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007f426143f75c [0x00007f426143f700+0x5c]
j  java.lang.ref.Finalizer$FinalizerThread.run()V+45
v  ~StubRoutines::call_stub

Edit: sometimes my machine crashes during the 2nd run, with a similar stack trace.

Note: this test might not be easily reproducible in 3.3.0 due to the issue described in PR #1330. I'll test current master branch next.

[stephengold]

Issue confirmed present in current master.

I recompiled jme3-bullet-native with cppCompiler.args "-D_DEBUG" and tried to reproduce the issue, but the app tripped a C++ assertion:

java: /home/sgold/Git/jmonkeyengine/jme3-bullet-native/bullet3-28039903b14c2aec28beff5b3609c9308b17e76a/src/BulletCollision/CollisionDispatch/btGhostObject.cpp:29: virtual btGhostObject::~btGhostObject(): Assertion `!m_overlappingObjects.size()' failed.
> Task :jme3-examples:run FAILED

This suggested the issue might relate to ghost objects. I tried to reproduce the original crash (without -D_DEBUG) using simpler jme3test apps. I was unsuccessful with TestIssue970 and TestBrickWall, but successful with TestAttachGhostObject and TestGhostObject.

From the comment in btGhostObject.cpp, it's apparent that Bullet expects the btGhostObject to be removed from the world before the btGhostObject is finalized.

[stephengold]

I wrote a simple test to trigger the C++ assertion:

    public void simpleInitApp() {
        CollisionShape shape = new SphereCollisionShape(1f);
        for (int i = 0; i < 10; ++i) {
            {
                PhysicsGhostObject a = new PhysicsGhostObject(shape);
                PhysicsGhostObject b = new PhysicsGhostObject(shape);
                PhysicsSpace space = new PhysicsSpace();
                space.add(a);
                space.add(b);
            }
            System.gc();
        }
        stop();
    }

[stephengold]

I believe this can be solved in the finalize() methods of PhysicsSpace and PhysicsCollisionObject.

Fixing only PhysicsSpace is probably insufficient, since there's no guarantee the PhysicsSpace will be finalized before the PhysicsCollisionObject. The fix to the PhysicsCollisionObject finalizer (to remove the object from any PhysicsSpace it's in) would involve the space field of the native jmeUserPointer class, which is currently not accessible from Java.

[stephengold]

I verified that this issue does not occur with jme3-jbullet. It's a native Bullet thing.

[stephengold]

The issue did not occur in JME 3.2.0 or 3.2.1; it seems to have crept in between JME 3.2.1 and 3.2.2 .

[ertugrulcetin]

hi @stephengold, Is there any update on this one?

I'm using jme3-bullet-native 3.2.2-stable and getting that error;

MacBookPro16,2 x86_64 2300 MHz, 8 cores, 32G, Darwin 19.6.0 / Version: 10.15.7

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000521cac922, pid=29715, tid=22787
#
# JRE version: OpenJDK Runtime Environment (15.0.1+9) (build 15.0.1+9-18)
# Java VM: OpenJDK 64-Bit Server VM (15.0.1+9-18, mixed mode, sharing, tiered, z gc, bsd-amd64)
# Problematic frame:
# C  [libbulletjme.dylib+0x110922]  btGhostPairCallback::removeOverlappingPair(btBroadphaseProxy*, btBroadphaseProxy*, btDispatcher*)+0x42
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   https://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.
#

[stephengold]

The workaround is to use Minie, preferably v3.0.0

Also, the crash report fragment you provided looks like a different issue. To be sure, I'd need to see the Java stack portion of the crash report.

[ertugrulcetin]

@stephengold I got the finalizeNative error. I'm using jme 3.3.2-stable and Minie 3.0.0.
Here is the whole error: https://gist.github.com/ertugrulcetin/18559a3db0895bc62f07600df08412e3

[stephengold]

That's an interesting issue. However, it looks like a Minie issue, not a JMonkeyEngine issue. JMonkeyEngine doesn't have a "PhysicsCleaner" thread. Furthermore, the crash didn't occur in PhysicsSpace.finalizeNative() but rather in PhysicsCollisionObject.finalizeNative(). So it's a definitely new/different issue.

Please open a new issue at https://github.com/stephengold/Minie/issues

Spoiler: if the issue is reproducible, my first request will be that you reproduce it using Minie-3.0.0+debug with assertions enabled.

[stephengold]

Closing as "wontfix" since native physics has been archived to a separate repo. Users who encounter this issue should consider switching to jme3-jbullet or Minie.