[SOLVED]Native Bullet always crashes on large amounts of rigid bodies

Troubleshooting physics
1

So it would appear that adding a large amount of physics objects to the physics space in a short amount of time causes bullet to reliably crash every time.

#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000674618ca, pid=8248, tid=8824
#
# JRE version: Java™ SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot™ 64-Bit Server VM (25.45-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [bulletjme.dll+0xa18ca]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\Vid\Desktop\eclipseGIT\Workspace\LightspeedFrontier\hs_err_pid8248.log
Compiled method (nm) 61705 8314 n 0 com.jme3.bullet.collision.PhysicsCollisionEvent::getAppliedImpulse (native)
total in heap [0x00000000035e2390,0x00000000035e2700] = 880
relocation [0x00000000035e24b0,0x00000000035e24f8] = 72
main code [0x00000000035e2500,0x00000000035e26f8] = 504
oops [0x00000000035e26f8,0x00000000035e2700] = 8
#
# If you would like to submit a bug report, please visit:
# Crash Report
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Here’s entire the mentioned report log.

2 Likes
2 
/*
 * Class:     com_jme3_bullet_collision_PhysicsCollisionEvent
 * Method:    getAppliedImpulse
 * Signature: (J)F
 */
JNIEXPORT jfloat JNICALL Java_com_jme3_bullet_collision_PhysicsCollisionEvent_getAppliedImpulse
  (JNIEnv * env, jobject object, jlong manifoldPointObjectId) {
    btManifoldPoint* mp = reinterpret_cast<btManifoldPoint*>(manifoldPointObjectId);
    if (mp == NULL) {
        jclass newExc = env->FindClass("java/lang/NullPointerException");
        env->ThrowNew(newExc, "The manifoldPoint does not exist.");
        return 0;
    }
    return mp -> m_appliedImpulse;
}

That’s the relevant code, so mp has to be invalid

1 Like
3

Ah yes, even worse. ¯\_(ツ)_/¯

4

Just curious, what is “large” and what is “short” in this case?

Just trying to predict how long it will be before I hit this same issue.

5

In my stress test case it was 2635 objects under a span of hmm…1,2? frames. Depends on when the enqueues actually got executed.

It does work alright if you do it slowly though, so I doubt you’ll have these problems.

And i’ll have to figure out yet another elaborate system to extend the adding time. :roll_eyes:

6

What is it that allows this many physics objects to run at the same time? Headless server?

I cant even run a few hundred without a severe frame rate hit. ie, down to 1 fps.

7

Depends on what you’re doing with those objects I guess. Mine are in a zero acceleration environment with no terrain geometry to collide with so they go to sleep once their initial speeds get slowly dampened away.

It does give me a very similar situation like the one you mentioned if they’re all in motion but it slowly gets better until it’s bottlenecked by the gpu rendering that many geometries.

It’s really an edge case though, when completely disassembling a massive spaceship and it’s expected to lag like all hell, but it really has no excuse to crash.

Just after adding (i had to split it into two parts for it to not crash on deconstruction):

After some expansion and sleep:

At that point, my gtx 760 can go no further, with the minimap taking a bunch of calls as well. Funny how this scene could’ve been 30 fps or more if Apple weren’t pompous pricks and decided not to support instancing.

1 Like
8

Looks like you‘re adding or removing single objects twice. I‘m supposing you didn‘t do a test case to see if it happens outside of your code as usually nobody around here does that :stuck_out_tongue:

1 Like
9

Hmm, now that’s odd. Isn’t the physics space designed to do nothing if you remove an object that it doesn’t have? I remember it handling remove(randomthingthatsnotevenrelatedtophysics) pretty well. Adding the same thing twice may be a very problematic I suppose. I shall take an extended look at it.

Aint nobody got time fo that :wink: Also since it always worked perfectly for everything below 1.5k at a time I didn’t give it any thought.

10

The check itself isn‘t really thread safe so you have all kinds of ways to mess it up in your code.

1 Like
11

Hmm so after some testing it would appear that making absolutely sure the thing isn’t on the physics space yet solves the problem. Now I gotta figure out just how in the actual f*** was that even possible to not be the case when just iterating through some child nodes that weren’t anywhere close to physics.