Second GlutDemoApplication causes crash.

Post Reply
Berezovsky
Posts: 14
Joined: Tue Oct 14, 2014 9:32 pm

Second GlutDemoApplication causes crash.

Post by Berezovsky »

Overflow in AABB, object removed from simulation
If you can reproduce this, please email bugs@continuousphysics.com

Please include above information, your Platform, version of OS.

Thanks.
I have heavily modified a GlutDemoApplication class for my own purposes, starting from code distributed with the Bullet SDK. The relevant demo source that I modified is found in this directory ....\bullet3-master\Demos\RagdollDemo

I call a function which creates a local instance of a RagdollDemo class.

Within that function, I call ::clientMoveAndDisplay() several thousand times, which in turn, invokes m_dynamicsWorld->stepSimulation() several thousand times.

The function then returns, causing the RagdollDemo class to ::exitPhysics() as per its destructor.

The interesting thing is that the crash and error shown above only happens on the second creation of the RagdollDemo class. It does not happen on the first call to the function. Further, it does not happen in all subsequent calls to the function (which creates a local class each time). It is as if it "gets something out of its system" and then works fine for the rest of them.

To give you an idea of what I mean by the "second creation", if I skip calling the function the second time, it bumps up the error to the third one. In any case, the second creation and run of the class causes the error.

For example:

Code: Select all

calling TaskThreadDebug( 0
weights on class 0 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 1
weights on class 1 OK.
Overflow in AABB, object removed from simulation
If you can reproduce this, please email bugs@continuousphysics.com

Please include above information, your Platform, version of OS.

Thanks.

returned from TaskThreadDebug() with timeStep = 987123124

calling TaskThreadDebug( 2
weights on class 2 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 3
weights on class 3 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 4
weights on class 4 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 5
weights on class 5 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 6
weights on class 6 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 7
weights on class 7 OK.
returned from TaskThreadDebug() with timeStep = 3001
I try to be clever, and skip the TaskThreadDebug(1) call. And this is what happens,

Code: Select all

calling TaskThreadDebug( 0
weights on class 0 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 2
weights on class 2 OK.
Overflow in AABB, object removed from simulation
If you can reproduce this, please email bugs@continuousphysics.com

Please include above information, your Platform, version of OS.

Thanks.

returned from TaskThreadDebug() with timeStep = 987123124

calling TaskThreadDebug( 3
weights on class 3 OK.
returned from TaskThreadDebug() with timeStep = 987123124

calling TaskThreadDebug( 4
weights on class 4 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 5
weights on class 5 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 6
weights on class 6 OK.
returned from TaskThreadDebug() with timeStep = 3001

calling TaskThreadDebug( 7
weights on class 7 OK.
returned from TaskThreadDebug() with timeStep = 3001
If I remove the (2)'th call, it bumps the error up to (3), and so on. I have heavily covered the simulation portion with "sanity checks" to make sure none of the rigid bodies are falling out of the sim or being 'flung' out of the AABB boundaries. None of these have yielded fruit into why this error happens.

(I will link my own code, below, in a response. I don't know how this forum handles outside links to pastebin)
Berezovsky
Posts: 14
Joined: Tue Oct 14, 2014 9:32 pm

Re: Second GlutDemoApplication causes crash.

Post by Berezovsky »

The part of the header containing the declaration of class RagdollDemo

http://pastebin.com/BaTddHmt
xexuxjy
Posts: 225
Joined: Wed Jan 07, 2009 11:43 am
Location: London

Re: Second GlutDemoApplication causes crash.

Post by xexuxjy »

hard to tell without all the code, but in general, make sure you remove all collision objects (rigid bodies, shapes, constraints) from the world before exit physics.
Berezovsky
Posts: 14
Joined: Tue Oct 14, 2014 9:32 pm

Re: Second GlutDemoApplication causes crash.

Post by Berezovsky »

Here is an extremely widdled-down version of the code, written in a top-to-bottom cpp file, with a main() at the bottom. This is for ease of conceptual digestion, for you to read to get a rough idea of what is happening.

http://pastebin.com/m2rJpUK7

Look over the code above and digest as much as you can to get a basic "feel" of what is happening here. This is for your benefit. Is the ::exitPhysics() function properly removing the 'fixedGround' btCollisionObject? I'm not really sure.

-------------- dramatic transition -------------------

Now here is the full code that is actually producing the error. Caveat -- This code works flawlessly the first time RagdollDemo object is created and run. And then it crashes with the above error on the second running after a second creation. Subsequent creations-and-runnings work flawlessly with no errors. Attempts to remove the 1st iteration, bumps the error up to the 2nd iteration. (removing the 2nd bumps to 3rd and so on). If you cannot understand anything that is happening in this code, go back and review the above link again, to see the basic outline.

Is the ::exitphysics() properly removing the fixedGround? Is it properly deleting the hinges and actuators? Should the constraints, hinges, and objects be deleted in a particular order? I'm not sure. Is there some other glaring problem?
Berezovsky
Posts: 14
Joined: Tue Oct 14, 2014 9:32 pm

Re: Second GlutDemoApplication causes crash.

Post by Berezovsky »

So far the methods above will create a singular RagdollDemo class, allowing it to exit itself and clean itself from memory. Only later is another one created locally and started up again. The exact error takes place after a single invocation of ::stepSimulation() . As described above, this happens always on the second created class, never on the first, and then never again for subsequent creations-and-runnings.

What is most interesting however, is what happens when you allocate all the RagdollDemos into global memory. You run ::initPhysics() (and other initializations) on all of them while they are still alive in memory. At this point, it becomes blatantly obvious that there is some sort of cross-talk happening between all of them.

While this avoids the crash, it causes their simulated behavior to be very wonky. In some strange way, the various class instantiations all "know" that the others are alive in memory and running simulation steps. In other words, the GlutDemoApplication is not entirely "encapsulated". It talks in strange ways through some global data, and therefore, various simultaneous instantiations will clash with each other.

The wonkiness is that correct behavior of the sim is only seen in the very last class in the list. That is, correct behavior only in the class which had ::initPhysics() called on it most recently in the past. So if there are 12 simulations kept alive-in-memory, only the 12th one exhibits correct behavior.

RagdollDemo is derived from base class GlutDemoApplication.
GlutDemoApplication is derived from base class DemoApplication

The header for DemoApplication is here http://pastebin.com/FzgGMYGr

In any case, what I need is a program with multiple, independent simulations, whom are all encapsulated in such a way that I can run ::stepSimulation() thousands of time in all of them without fear of cross-talk. Ideally I should be able to allocate, de-allocate, start, stop, and whatever else with no effect on the sibling simulations or their parameters, or their data.
xexuxjy
Posts: 225
Joined: Wed Jan 07, 2009 11:43 am
Location: London

Re: Second GlutDemoApplication causes crash.

Post by xexuxjy »

Again, a bit of a guess, but comparing to the standard ragdoll physics demo you might want to remove all your constraints (joints,welds) first, then remove the bodies. Also I wasn't sure what :

i=0;
while(i<nocans) {
if( i != 14 ){ DeleteObject(i); }
i++;
}

was supposed to do, why is one object being left behind?
Post Reply