EXCEPTION_ACCESS_VIOLATION - C [odejava.dll+0xa9e4b]

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.



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.



cvs = development version

I'm not able to reproduce that here :expressionless: - 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 :expressionless:

I wonder what part of the code that does this… :frowning:

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 


DELL laptop:      Pentium M Processor x86 Family 6 Model 13 Stepping 8 GenuineIntel ~797 Mhz


Toshiba laptop:  Pention 4 Processor x86 Family 15 Model 3 Stepping 4 GenuineIntel ~3200 Mhz


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 :wink:

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 :expressionless: (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. :slight_smile:

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)