Hello all,
Just as a quick up date. I have managed to debug my code to find where this problem is located. I am running the TestGenerateTerrain.java program that comes with the jME Physics engine. I have put a block on following code
public static void dGeomTriMeshDataSet( SWIGTYPE_p_dxTriMeshData g, int data_id, SWIGTYPE_p_void in_data ) {
OdeJNI.dGeomTriMeshDataSet( SWIGTYPE_p_dxTriMeshData.getCPtr( g ), data_id, SWIGTYPE_p_void.getCPtr( in_data ) );
}
in the Ode.java file located in org.odejava.ode. One thing that I noticed is that this method is called 22 times on startup and it is on the 22 iteration that the exception occurs.
I am not sure if this is any help.
Regards
Paul
This problem should be fixed in the development version. Do you use a beta release or current cvs?
Hi, I get the same problem mentioned above. By the way, I use jmephysics from the cvs.
Hi Irrisor,
I am using the version from CVS. Is the development version already out or are you due to release it soon.
Regards
Paul
cvs = development version
I'm not able to reproduce that here 
- I'll try to have a look on a dual core machine, though as it does not use threads that should not matter, strange . . . :?
My machine is not dual core though… It's athlon xp 3000+, 1.5GB RAM, and radeon 9600XT graphic card…
mmm, dual core didn't cause any problems and your machine, explorer, seems quite like mine… really no idea why it's failing for you
I wonder what part of the code that does this… 
Anyone with an installed c++ debugger who can reproduce that problem?
I also got a JVM crash when running the latest CVS version of TestGenerateTerrain.
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x045c9e4b, pid=5416, tid=2176
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode)
# Problematic frame:
# C [odejava.dll+0xa9e4b]
#
# An error report file with more information is saved as hs_err_pid5416.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
All other jmephysics test classes ran fine.
However I did get it to work by turning JIT compilation off with the VM arg "-Xint".
Maybe you can give that a try.
Oh, and I should add that I also ran the latest TestGenerateTerrain from CVS and it also crashes with the same problem. Lemme know if I can be of any help running additional tests.
Ok, I've tried another machine. This time a Toshiba laptop running WinXP HOME edition. It crashed in the same place thus crushing my last theory. :oops:
All three machines have a Intel chips but different processors. Could this be an issue?
HP workstation: Pention 4 Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~2800 Mhz
WORKS!
DELL laptop: Pentium M Processor x86 Family 6 Model 13 Stepping 8 GenuineIntel ~797 Mhz
CRASHES
Toshiba laptop: Pention 4 Processor x86 Family 15 Model 3 Stepping 4 GenuineIntel ~3200 Mhz
CRASHES
I'm trying to find a pattern here… are there any C library calls used by odejava that could be system related?
FuzzyDuck said:
I'm trying to find a pattern here... are there any C library calls used by odejava that could be system related?
Not that I know of... very strange issue :|
Hi Irrisor,
Yeah it is… I'm using the same game installation with the same game code and libs (jars and dlls) on all three machines. :?
Although I have this problem, I'm in the lucky (??) situation where i have a machine where it works and another where it doesn't… Which should make troubleshooting it easier.
I'm wondering if DarkProphet/Per/yourself have any suggestions for me to follow?
DarkProphet gave up any jME development before jME Physics 2 was even started. Per does not have the time and did not participate in jME Physics 2 deveopment either. So I don't expect any help from them 
And the only thing I can tell you currently as I don't understand the problem, either, is: take a (c++) debugger and try to find out (I don't have a system myslef that exposes this behaviour and don't have the time to investigate)
Oh dear… sounds like you’re on your own? :’(
I’ll try my best to debug it on one of those machines.
I havn’t discounted anything yet… it could be something dumb in my code… :?
BTW, what type of video card do you have? One of my machines has a NVIDIA and the other two (where it crashes) are ATI cards. Just another possibility.
Thanks Irrisor.
There's no need to fear…darkfrog's still here. :-p
…even though it's been quite a while since I've done anything with physics I will be back to it on my next game most likely.
physics works without even having a graphics card, so that shouldn't affect anything
darkfrog - I thought that might have stirred you from the shadows. 
Ok, I've tried a few more things with no success, but today I'll compile a debug version of odejava and step through it with the VS C++ debugger.
I was having a separate issue with audio streaming and that was fixed with a sound driver upgrade… hence why i thought about a possible problem with graphics cards.
Just had an idea: last transform really should not be needed for trimeshes in static nodes. So I can remove the update of it at least for terrain. Dynamic trimeshes will still have the problem though…
I have altered the cvs-version. TestGenerateTerrain should be fine now. (TestBasicRepresentation with useTriMesh = true could still fail though)