Odejava - Stack overflow

Hi,



I've just encountered this awful "exception".



An unrecoverable stack overflow has occurred.

#

An unexpected error has been detected by HotSpot Virtual Machine:

#

#  EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x40f8f797, pid=1552, tid=2540

#

Java VM: Java HotSpot™ Client VM (1.5.0_13-b05 mixed mode)

Problematic frame:

C  [odejava.dll+0x6f797]

#

An error report file with more information is saved as hs_err_pid1552.log

#

If you would like to submit a bug report, please visit:

http://java.sun.com/webapps/bugreport/crash.jsp

#




Does anyone knows what can be the cause of this?



In my application I have a ship, which is composed of few components. Each component is represented as a DynamicPhysicalNode. These PhysicalNodes are all connected to one of them (Cabin… it is a topologic star) via the Joints. So the "physical movement" by engines etc… is done by applying forces on the Cabins PhysicalNode and whole ship with all its components moves. However when the ship reaches the boundary of the screen I want it to flip on the other side of the screen (if ship crosses the left screen side it appears at the right screen side and vice versa). For this "non-physical movement" I have an ordinary Node called shipNode which children are all those DynamicPhysicalNodes of all ship components. To perform that flip movement I set the correct position to the shipNode and therefore whole ship is flipped on the other side of the screen.

However after such a flip next PhysicsSpace.update(float) method call produces the error you can see above:-(…



Does anyone have an idea what is wrong?

Thanks for advice




  1. you're most probably better off using a single dynamic node and put several geoms in there instead of using joints to connect them
  2. the stack overflow is most likely caused by a too high contact count in ODE - if you find out why so many contacts are created (why so many collisions occur) you can fix it by decreasing the number of contacts/collisions (or increase stack size, but that's not the solution in your case).



    Maybe your ship's components are colliding with each other? Start with using only 3 components and 'beam' the ship only a little bit to see what's happening if you do not want to go for 1.

Hi,



the first possibility is not applicable for me, because I want to make the ship partially destroyable - if you hit the engine, engine will be destroyed and detached from the ship… therefore it has to have its own physicalNode… But if you have any idea how to achieve this functionality in a simplier way come up with it:-) Because I have had many troubles with such a complicated ship structure so far:-)



in the second remark you are right - my components (their physicalNodes) are colliding with each other. But I didn't care about it because javadoc says that nodes connected by joints does not collide with each other, but now I see it is meant that the result of collision is not computed but the collision itself occurs somewhere and it is stored. Am I right?

This also makes me troubles that during this flip ship sometimes destroys itself:) Undoubtably by the collisions between components…

gorgor said:

the first possibility is not applicable for me, because I want to make the ship partially destroyable - if you hit the engine, engine will be destroyed and detached from the ship.. therefore it has to have its own physicalNode...

that's not true. You can still react on collisions for the single geoms, to count taken damage. If a part should 'fall off' you can detach it from the common node and create a separate node for it.

gorgor said:

in the second remark you are right - my components (their physicalNodes) are colliding with each other. But I didn't care about it because javadoc says that nodes connected by joints does not collide with each other, but now I see it is meant that the result of collision is not computed but the collision itself occurs somewhere and it is stored. Am I right?

No. Joint nodes do not collide with each other (by default) that's right. But if you join A and B, as well as B and C; A and C still collide! Ignored contacts do not cause trouble as they do not result in any contact joints in ODE. So you could register a custom contact callback (physicsSpace.getContactCallbacks().add(...)) and ignore all reported contacts between your ship's components if you really want to keep the separated nodes.
gorgor said:

irrisor said:

the first possibility is not applicable for me, because I want to make the ship partially destroyable - if you hit the engine, engine will be destroyed and detached from the ship.. therefore it has to have its own physicalNode...

that's not true. You can still react on collisions for the single geoms, to count taken damage. If a part should 'fall off' you can detach it from the common node and create a separate node for it.


It is true that I can react on the collision and I can also detach the component and make a new physical node  for it. I actualy went this way in past but then I didn't find a way how to distinguish between hitting the component  A or component B. It was all one node which was hit but I want also to be able to distinguish whether component A was hit or component B was hit. Because all components has its life and they live as long as they are not hit many times...


gorgor said:


irrisor said:

in the second remark you are right - my components (their physicalNodes) are colliding with each other. But I didn't care about it because javadoc says that nodes connected by joints does not collide with each other, but now I see it is meant that the result of collision is not computed but the collision itself occurs somewhere and it is stored. Am I right?

No. Joint nodes do not collide with each other (by default) that's right. But if you join A and B, as well as B and C; A and C still collide! Ignored contacts do not cause trouble as they do not result in any contact joints in ODE. So you could register a custom contact callback (physicsSpace.getContactCallbacks().add(...)) and ignore all reported contacts between your ship's components if you really want to keep the separated nodes.


Yea, I am aware that joining A with B and B with C does not make A and C non-collidable, but it is (seems to me) not possible to occurs this, because even though all components are connected to Cabin they are quite apart from each other. And while flying the space no collisions are detected. However I do not know exactly what happens during that "non-physical movement" because it is the only moment when collisions occurs:-(

I'll look at the physicsSpace.getContactCallbacks() because till now I resolve collisions using InputHandler and physSpace.getCollisionEventHandler().

Hi,



so I added the

physSpace.getContactCallbacks().add(new ContactCallback(){…});

into my physSpace. ContactCallback just check whether colliding nodes are from the same ship and if so, then it setIgnored(true) to the given PendingContact and count it. One flip of the ship usually generates around 700-800 collisions which are now ignored. And once it was even 5247 before it craches by the overflow! OMG, there is a mistake, and not a small one:-)



Have you any idea what can generate so many colllisions? Can the PhysicalNodes be safely moved by setLocalTranslation() method when they are jointed? Can not this generate such a huge amount of collisions?

You can distinguish between the parts of a node by mapping the physics collision geometries (physical children of the node) to your components.



Maybe you should try what I suggested (move a little with only 3 components) to see what's going on?

Are you emptying your contact joint group each frame? If not, then you will slowly leak contact joints, and eventually run out of stack space.

Also, the step function you use matters. I think StepFast() is the best trade-off between quality and performance/resource usage.

jwatte said:

Are you emptying your contact joint group each frame?

He is. (Though he most probably does not know it ;) - jME Physics 2 hides these ODE details)

The default is quickStep - I assume that's the one used in this case, too.

I think the actual problem is caused by geoms which should not even intersect.

gorgor, did you say that even with all contacts ignored the app crashes? If yes, we're dealing with another problem here.

Hi,



about the ode things - I really do not know, but as Irrisor said I probably empty it, because jME physics does it:-) and the step is the default one in my case.



I add this to my code where my physicsSpace is created


physSpace = PhysicsSpace.create();
physSpace.getContactCallbacks().add( new ContactCallback() {
          public boolean adjustContact( PendingContact contact ) {
             contact.setIgnored(true);
             return true;
                         }
}



and that overflow exception is still thrown.
I'm quite confused now:-(

So, I've localized the error. It is of course in my code, when I set the location of the whole ship I set there also all components positions at their default values (values along the point (0,0,0) but different to make correct ship) and then I set their parenting node to the place I want the ship. This somehow makes the component collide each other. Now if I simply set position only of the parenting node it seems to work fine. Even if I set only all components and not the parenting node it works fine too…

A little conclusion : my old way of translating based upon the idea of reset position at default and translate at desired position somehow sucks:-(



Nevertheless my last post still holds. My weird translating method is able to crash the application even with the posted ContactCallback.