Java/JNI throws exception but DRAWEXE okay!

I have a number of example STEP models I'm testing with OCC 6.3 on Windows (Vista64).

First I Open them using DRAWEXE (MDTV-XCAF) and SaveAs them (as *.dxc files). Later, I can Open all the dxc files using DRAWEXE. XShow works perfectly.

Next I developed some Java code (based on the java/samples code) to emulate what DRAWEXE does, for Open and XShow. The smaller models work perfectly.

However, the larger models (7MB dxc file) do not.
Increasing JVM memory does not solve the problem.

I used this to determine the crash location:

BRepMesh_FastDiscret::Add(const TopoDS_Face& theface)
just below the "//clear the structure of links" at the line:

I also tried opening these files directly using the samples/java program "Import/Export STEP". It also crashes in the same place.

64bit Java using 64bit libraries fails there too.

Spent a couple of weeks getting this far.
Can anyone give me advice on how to fix this?
Are am I screwed...

scottw_56867's picture

MMGT_OPT needs to be set to 1

I probably set this to 0 after reading Roman's blog on parallel applications, since I'm going to need to do parallel eventually.

Perhaps this is fixed on the version he is using with CAD Exchanger (6.3.0 with patches or 6.3.1).

Or more likely it's because I'm using Java/JNI (remember, this works okay with C++).

Pawel's picture

Hi Scott,

I ran into the same issue with pure C++. BRepMesh_FastDiscret::Add crashes in some cases on the line:


In my case it happens with the debug version of OCC only. MMGT_OPT was set to 0.

To tell the truth it seems to be a bug to me.

The algorithm iterates through a map (MeshDS_MapOfInteger& aLinks)
that changes its size (ForseRemoveLink changes the size of the map) during the iteration - that can be easily observed in the debugger.

Setting MMGT_OPT to 1 probably hides the issue as the memory is intact during the iteration.

Can anyone from the OCC team confirm this?