Java JNI Signal Handlers and OpenMP

[tahamsh2]

We are trying to use a DSP library written in C++ compiled with OpenMP 10.1.008 and using the MKL 10.0.010 library in our Java 6 application. We have wrapped the DSP library using JNI in order to use it in Java. This software architecture worked with MKL 9, and we are now having issues integrating an updated version of the DSP library which now uses MKL 10. Using the -Xcheck:jni option while running our Java code, we receive warnings that libguide.so has replaced libjvm.so handlers for the following signals: SIGSEGV, SIGILL, SIGFPE, SIGBUS, SIGPIPE, SIGHUP, SIGINT, SIGTERM, and SIGQUIT. A little searching revealed that Java JNI (libjvm.so) needs to be the first signal handler and subsequent native handlers should be chained after it. It looks like libguide.so just overwrites the libjvm.so handlers. My question: is there a way to force OpenMP/MKL threading libraries to chain signal handlers rather than taken them over completely?

The only not-so-pretty workaround I have found so far requires setting LD_PRELOAD=/lib-path/libjsig.so before running our code, allowing the jsig library to setup signal handler chaining prior to guide stomping existing handlers. Hopefully, theres a better way for Java and MKL 10 to coexist.

Platform: RedHat 5 64-bit, compiled as 32-bit shared libraries

[jimdempseyatthecove]

Quoting - tahamsh2

We are trying to use a DSP library written in C++ compiled with OpenMP 10.1.008 and using the MKL 10.0.010 library in our Java 6 application. We have wrapped the DSP library using JNI in order to use it in Java. This software architecture worked with MKL 9, and we are now having issues integrating an updated version of the DSP library which now uses MKL 10. Using the -Xcheck:jni option while running our Java code, we receive warnings that libguide.so has replaced libjvm.so handlers for the following signals: SIGSEGV, SIGILL, SIGFPE, SIGBUS, SIGPIPE, SIGHUP, SIGINT, SIGTERM, and SIGQUIT. A little searching revealed that Java JNI (libjvm.so) needs to be the first signal handler and subsequent native handlers should be chained after it. It looks like libguide.so just overwrites the libjvm.so handlers. My question: is there a way to force OpenMP/MKL threading libraries to chain signal handlers rather than taken them over completely?

The only not-so-pretty workaround I have found so far requires setting LD_PRELOAD=/lib-path/libjsig.so before running our code, allowing the jsig library to setup signal handler chaining prior to guide stomping existing handlers. Hopefully, theres a better way for Java and MKL 10 to coexist.

Platform: RedHat 5 64-bit, compiled as 32-bit shared libraries

I cannot recall the specifics without doing a search (you can do that with the following hints). I had a similar problem under Windows where the normal program flow would call something inthe DLL I wanted loaded second, first. Thus mucking up which DLL I wanted to use. Windows has a function (Linux likely has one too) which you specify a library and entry point and the function loads the DLL and binds the dispatch table with the address within the DLL. i.e. the first load DLL is a specific one you name rather than those you run accross in first come first serve (and by way of LIB search path rules).

Search your API documentation for "load library" "load DLL" "load order" etc...

Jim Dempsey