Crashes with OdeJava

Hi



I'm using JMonkey with odejava (both newest versions) but getting instant native crashes when something collide.

I've tried increasing the stacksize (up to 50 mb ) with no result.

Strange thing is, this only happen when I use step()  and not stepFast(). I can't use stepfast because it's too inaccurate.

The same physics code is running with no problem using java3d…so what could it be ?



Thanks,



Baune



Heres the crash-report


2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child () attached to this node (rootNode)
2006-01-06 09:27:48 com.jme.scene.Node <init>
INFO: Node created.
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child () attached to this node ()
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child () attached to this node (rootNode)
2006-01-06 09:27:48 com.jme.scene.Node <init>
INFO: Node created.
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child () attached to this node ()
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child () attached to this node (rootNode)
2006-01-06 09:27:48 com.jme.scene.Node <init>
INFO: Node created.
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child () attached to this node ()
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child () attached to this node (rootNode)
2006-01-06 09:27:48 com.jme.scene.Node <init>
INFO: Node created.
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (gauge) attached to this node (Gauge)
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (Gauge) attached to this node (rootNode)
2006-01-06 09:27:48 com.jme.scene.Node <init>
INFO: Node created.
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (north) attached to this node (skybox)
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (south) attached to this node (skybox)
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (east) attached to this node (skybox)
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (west) attached to this node (skybox)
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (up) attached to this node (skybox)
2006-01-06 09:27:48 com.jme.scene.Node attachChild
INFO: Child (down) attached to this node (skybox)
2006-01-06 09:27:50 com.jme.scene.Node attachChild
INFO: Child (skybox) attached to this node (rootNode)
An unrecoverable stack overflow has occurred.
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x0fe73ff7, pid=1424, tid=2880
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode)
# Problematic frame:
# C  [odejava.dll+0x53ff7]
#
# An error report file with more information is saved as hs_err_pid1424.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#


I wouldn't call it strange, as it is already mentioned in the ode docs that way (more stack size problems with step than faststep).

Did you really increase the native stack size? To do that you have to

  1. run the vm with e.g.  -Xss1M
  2. spawn a new thread where you run your physics computation!  (the stack size parameter does not affect the main thread)



    Hope that helps.



    Btw. as you most probably know we are using ode in jmephysics - do you use that? Or odejava?

It all runs in the same thread. I'll try to use seperate threads. Yes I

did use Xss50M…

I can't use the Jmonkey binding to ODE yet because all my previous code for this

project is hooked up on OdeJava. But maybe next time… Thanks !


irrisor said:

2. spawn a new thread where you run your physics computation!  (the stack size parameter does not affect the main thread)

OOPS !. That helped. Thanks again :)

Now the only problem is some flickering…since the physics loop are alterering the nodes at the same time as the screen is updating…

Any hint on how to prevent that ?

Yes - do it in one thread! Namely call the step function from the jme update method (or simpleUpdate) and adjust all geometry data after that.



You can do more complicated stuff to speed things up on mutiprocessor systems (some people like to support that with jmephysics) but in my oppinion that's too much headache for a little performance gain (and on single proc systems you might even loose some speed).

Hey people, I am having the same problem this guy did two years ago and I tried the solution y'all recommended but it isn't working for me.  Specifically, I use the slow step function instead of the quick one, and with only a dozen or so objects, a collision will pretty quickly cause a stack overflow in the ODE DLL.  I set a ludicrously high Xss value and caused the function that ultimately calls step() or whatever (as well as the rendering logic) to be run in its own special thread, yet the problem is unchanged.  Any thoughts?  Why do virtual machine designers make it so hard to change stack sizes?!?

That's a known ODE limitation with the step function. The ODE community suggests to use quickStep and/or a high stack size to circumvent it… another possibility would be to replcace alloca calls with mallocs in the natives, but this causes memory leaks and is a lot slower… so there is no really good solution available for ODE based simulations with high contact counts :frowning:

But isn't the point of the solution you recommended previously to increase the stack size?

OH AND ALSO.  You suggest that ODE may be altered via the replacement of stack allocations with heap allocations–wouldn't that actually work, and be fast, if a proper custom memory manager were used, like with overriding of operator "new"?  Well I guess that is C++ and maybe ODE wouldn't support it…  ?  Oh well I suppose that's outside your purview anyway since this isn't the ODE forums!

Bananadine said:


         }}).run();



That's the problem: you don't use the thread but call the method in the current thread! You need to call start() instead of run().

ODE already has a macro to switch from alloca to malloc, it just didn't work well for me.

Quote:
That's the problem: you don't use the thread but call the method in the current thread! You need to call start() instead of run().

Hahahaha well that certainly weakens my argument, doesn't it!

There is a 2D Java physics engine somewhere just forgot the name of it.