access violations when calling IMSL from JNI

[lewijam]

I'vewrappeda number of IMSL routines in C and placed them in a DLL that I call from Java through the JNI. I recently added a call to the linear programming routine DD2PRS and rebuilt the DLL with CVF 6.6. Now I'm getting access violations from within the IMSL call:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x77FCCA36
Function=RtlFreeHeap+0x263
Library=C:WINNTsystem32 tdll.dll

It looks like a compiler/linker problem to me, since (1)the JNI callworks fine for small inputs, (2)the DLLworks fine when I call it from a stand-alone main in C, and (3)the JNI callworks if instead of passing in the arguments from the JNI, I pass in identical dummies (I've inspected all the inputs, and they really areidentical).

It seems suspicious that the IMSL code even calls RtlFreeHeap, since I'm passing in work space, and I don't think it should be allocating/freeing any memory. I'm stumped.

[Steven_L_Intel1]

I doubt it's a compiler or linker problem, but it could bea mismatch in libraries. Try different settings for the "use run-time libraries" option when building your DLL.

I'll note that IMSL 5 in Intel Visual Fortran Professional includes a DLL form of the IMSL libraries.

[lewijam]

Inconsistent runtime libraries seemed like a likely culprit, but I've tried every possible combination, and itdoesn't make anydifference. Since the JVM loads msvcrt, I would think msvcrt/dfordll would be the right libraries to link to, but the only change this made was to prevent the exception handler from finding the function name.

As for upgrading the compiler, I'm more than happy to do it if you think it'll help (or if I have to to get support), but I'd actually prefer not to have to distribute another dll. Is there some reason that only the dll version of the imsl library should be compatible with the JNI?

[Steven_L_Intel1]

I have no idea, really. I have never used JNI - was just trying to offer general suggestions. I can't do more than that for CVF.

[lewijam]

Understood. But how should I go about getting support? If I upgrade to the IntelProfessionalCompilerand the problem doesn't go away, would somebody at Intel look into it?

[Steven_L_Intel1]

Yes, we would do our best with this. There's clearly some odd interaction with JNI, but it would be good if we understood it.

[lewijam]

Steve,

It took a while, but Ifinally upgraded to the Intel Fortran Compiler and IMSL 5.0, and I'm getting exactly the same behavior. Are you still willing to look at this, and if so, how should we proceed?

Jim

[Steven_L_Intel1]

Yes, we would be willing to take a look, but.. Which form of the IMSL libraries are you using? Have you tried the DLL form? What happens if you build your DLL as a "Release" configuration?

[lewijam]

I just tried building release configurations against both the static and dll versions of the IMSL library, and I'm getting the same error no matter what. I've been linking to the multi-threaded dll C runtime, which means that I load MSVCR71.dll at runtime.I tried linking to the static runtime, but the linker complained about an unresolved _main. I think I used to know why this happens...

With the Compaq compiler, I got the same error no matter what C runtime I used. I believe Ishould be using the mult-threaded dll, since the JVM links in MSVCRT.

[Steven_L_Intel1]

If you can put together a ZIP file with everything we need to reproduce the problem, send it to support, ask that it be assigned to Steve Lionel, and I'll take a look.

[lewijam]

My bad all along (of course)! Turns out I was passing an array of the wrong size for one of the outputs. Many thanks to Steve for helping me out on this.