After switching to the 10-30-04 lib and binary, the native library crashes when I try to remove a Geom from a Space. The crash seems to be caused by the Ode.getPARENTSPACEID_ZERO() call. Is anyone else having similar issues?
I seem to be having the same problem with Body.removeGeom() and Ode.getBODYID_ZERO() 
Which platform?
Which version (debug/release)?
What is the error message?
Geom removal seems to be working for me (Mac/debug).
Will.
Running Windows XP, J2SE 1.5.0, 10-30-04 cvs and natives. Error message is:
An unexpected error has been detected by HotSpot Virtual Machine:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x377c7aaa, pid=1068, tid=2868
Java VM: Java HotSpot™ Client VM (1.5.0-b64 mixed mode)
Problematic frame:
C [odejava.dll+0x57aaa]
An error report file with more information is saved as hs_err_pid1068.log
If you would like to submit a bug report, please visit:
http://java.sun.com/webapps/bugreport/crash.jsp
Here’s the first few lines of the logged stack trace:
Stack: [0x376b0000,0x376f0000), sp=0x376ef2e8, free space=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [odejava.dll+0x57aaa]
C [odejava.dll+0x5461e]
j org.odejava.ode.Ode.getPARENTSPACEID_ZERO()Lorg/odejava/ode/SWIGTYPE_p_dSpace
ID;+4
j org.odejava.Geom.removeFromSpace()V+35
j org.odejava.Space.remove(Lorg/odejava/Geom;)V+22
This method call seems benign… any idea what I might be doing to cause the crash?
My code worked with the 5-29-04 natives and 9-7-04 cvs, so I’m not sure what I’m doing swong…
I think your code is finding the wrong instance of the odejava.dll. That is, you’ve still got the old one being found in your system and not the newly recompiled one.
I thought that might be the case, so I deleted the old .dll, ran to make sure that odejava.dll was not found, and then copied over the new one. This didn’t seem to have any effect.
I’ve experimented with this phenomenon on several machines now. The problem seems to be related to the execution time that passes between Space creation and adding the GeomS to the Space. If I create the Space and then immediately add GeomS to it, then I can not subsequently remove those GeomS without crashing the VM. All seems well if I place some seemingly extraneous startup statements (e.g. initializing GUI components) between Space creation and Geom adding. Does this make any sense? Are JNI calls synchronous? At the very least, maybe this can help someone 
What puzzles me with this is that it is crashing on Ode.getPARENTSPACEID_ZERO(). I have experianced crashes when removing a geom twice (it would crash the second time as it didn’t exist). I have added some safeguards to the API to prevent this case.
As far as I know, the ZERO Space is always present in ODE.
Have you tried increasing the available java heap memory? It’s a long shot, but solved (read: worked around) a problem I had once.
Will.
When I began using Odejava (5-29 natives, 9-7 cvs), I was using a starting heap size of 128M and a max heap size of 256M. I was experiencing some native crashes, so I upped the starting heap size to 256M and the max heap size to 512M, which seemed to take care of the problem.
The crashes returned after I switched to the newest natives and cvs. The crashes seemed to go away after I switched around some of my program initialization statements. I have even lowered the starting heap size back to 128M and the max heap size to 256M, and Odejava seems to be running rock solid! I can’t make much sense of it
nasty native memory bugs I think 
Will.
sorry if this seems to be out of place, but have you tried it on linux or macosx?
Because it seems (to me atleast) that windows is allocating space in memory to the JVM that is already being actively used by Ode natives…
Its a very longshot…but worth the try i guess.
Sorry for such a dumb comment, but ive never trusted windows.
DP
No, I haven’t tried running on linux or macosx. Unfortunately, I prematurely ported my code to java 1.5, so I am now waiting for a macosx release of java 1.5. I also don’t have easy access to a linux box at the moment, though I could bug some friends. Thanks for the tip!