dcsimg
Using JNI to call Fortran Modules
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Sarosh_Arunkumar
Posted On:   Monday, May 10, 2004 01:30 PM

Hi, I have a program written in Fortran 90 which I would like to call using JNI. Basically, I've generated the required C++ header using JNI, written my C++ code accordingly (meaning, it conforms to what JNI needs and it calls the main module which calls all the other subroutines), and then using Visual C++ 6.0 and Compaq Visual Fortran 6.6, I've compiled my Fortran files and C++ files into a DLL for my java executable. The program runs fine for a little while, but on one particular line of code, it crashes and generates this error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_STACK_OVERFLOW (0xc00000fd) occurred at PC=0x2CD33FF    More>>
			
Hi,

I have a program written in Fortran 90 which I would like to call using JNI. Basically, I've generated the required C++ header using JNI, written
my C++ code accordingly (meaning, it conforms to what JNI needs and it calls the main module which calls all the other subroutines), and then
using Visual C++ 6.0 and Compaq Visual Fortran 6.6, I've compiled my Fortran files and C++ files into a DLL for my java executable.

The program runs fine for a little while, but on one particular line of code, it crashes and generates this error:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_STACK_OVERFLOW (0xc00000fd) occurred at PC=0x2CD33FF
Function=Java_fds_main_1sub+0x723FF
Library=H:j2sdk1.4.2_04 inFDS.dll

Current Java thread:
at fds.main_sub(Native Method)
at fds.main(fds.java:6)

Dynamic libraries:
0x00400000 - 0x00406000 H:j2sdk1.4.2_04 injava.exe
0x77F50000 - 0x77FF7000 C:WINDOWSSystem32
tdll.dll
0x77E60000 - 0x77F46000 C:WINDOWSsystem32kernel32.dll
0x77DD0000 - 0x77E5D000 C:WINDOWSsystem32ADVAPI32.dll
0x78000000 - 0x78087000 C:WINDOWSsystem32RPCRT4.dll
0x77C10000 - 0x77C63000 C:WINDOWSsystem32MSVCRT.dll
0x08000000 - 0x08138000 H:j2sdk1.4.2_04jre inclientjvm.dll
0x77D40000 - 0x77DCC000 C:WINDOWSsystem32USER32.dll
0x7E090000 - 0x7E0D1000 C:WINDOWSsystem32GDI32.dll
0x76B40000 - 0x76B6C000 C:WINDOWSSystem32WINMM.dll
0x10000000 - 0x10007000 H:j2sdk1.4.2_04jre inhpi.dll
0x00390000 - 0x0039E000 H:j2sdk1.4.2_04jre inverify.dll
0x003A0000 - 0x003B9000 H:j2sdk1.4.2_04jre injava.dll
0x003C0000 - 0x003CD000 H:j2sdk1.4.2_04jre inzip.dll
0x02C60000 - 0x02F46000 H:j2sdk1.4.2_04 inFDS.dll
0x02F50000 - 0x02FC5000 C:WINDOWSSystem32DFORRT.DLL
0x76C90000 - 0x76CB2000 C:WINDOWSsystem32imagehlp.dll
0x6D510000 - 0x6D58D000 C:WINDOWSsystem32DBGHELP.dll
0x77C00000 - 0x77C07000 C:WINDOWSsystem32VERSION.dll
0x76BF0000 - 0x76BFB000 C:WINDOWSSystem32PSAPI.DLL

Heap at VM Abort:
Heap
def new generation total 576K, used 112K [0x10010000, 0x100b0000, 0x104f0000)
eden space 512K, 21% used [0x10010000, 0x1002c0f8, 0x10090000)
from space 64K, 0% used [0x10090000, 0x10090000, 0x100a0000)
to space 64K, 0% used [0x100a0000, 0x100a0000, 0x100b0000)
tenured generation total 1408K, used 0K [0x104f0000, 0x10650000, 0x14010000)
the space 1408K, 0% used [0x104f0000, 0x104f0000, 0x104f0200, 0x10650000)
compacting perm gen total 4096K, used 975K [0x14010000, 0x14410000, 0x18010000)
the space 4096K, 23% used [0x14010000, 0x14103cb0, 0x14103e00, 0x14410000)

Local Time = Mon May 10 15:03:20 2004
Elapsed Time = 1
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode)
#


Does anyone have any hints as to how to deal with this? The reason I'm having trouble with this is because the Fortran code by itself works
just fine, so I'm not sure where to look for the problem.

Thanks!

Sarosh
   <<Less

Re: Using JNI to call Fortran Modules

Posted By:   Christopher_Koenigsberg  
Posted On:   Monday, May 10, 2004 02:45 PM

Your error is coming from the HotSpot JIT compiler, I think.... try disabling it (how to do this depends on your config and how you are running a JVM), so your Java bytecode is just run in the JVM, without it trying to compile to native binary first.


I have seen weird errors coming from HotSpot compilers before, that disappear when you just run the JVM without compiling... for instance a Weblogic server would crash sometimes, in random places during some memory-intense operations, until we got a tip from BEA by way of someone else, about disabling the HotSpot JIT....

About | Sitemap | Contact