What does "consider using jsig library" mean?

Question

I'm running a Java program which uses JNI with the -Xcheck:jni flag, and I'm getting messages that look like this:

SIGSEGV: [libjvm.so+0x6fd190], sa_mask[0]=0x00000400, sa_flags=0x10000000, flags was changed from 0x10000004, consider using jsig library

What does that mean? Should I be concerned? What is the jsig library?

I'm using Java 7 on Linux, or to be exact:

JRE version: 7.0_03-b04
Java VM: Java HotSpot(TM) 64-Bit Server VM (22.1-b02 mixed mode linux-amd64 compressed oops)

Answer 1

Some more details, because documentation on signal chaining is a bit sparse:

The Java VM (at least Oracles implementation, which also includes the OpenJDK) uses POSIX signals for internal communication, so it installs signal handlers e.g. for SIGSEGV. That means, to work correctly, the Java VM must get and examine any SIGSEGV which happens in the process, to distinguish between "communication" SIGSEGVs and real ones which would be program errors.

But signal handlers are a global resource, within a process any native code can install signal handlers and replace the ones the Java VM installed.

-Xcheck:jni causes the VM to run periodic checks, among other things, whether someone changed the signal handlers from under the Java VM. If it detects a change, it prints a warning.

To solve this problem (user-installed signal handlers replace the JavaVM signal handlers) and to accomodate user code which may have a reason to install signal handlers, Java VM uses "signal chainging", which basically means that the signal handlers (VM and Users) are chained behind each other: the JavaVM signal handlers run first; if they think the signal is of no interest to the VM, it hands down the signal to the user handler.

There are two ways to active this support: 1) use your own native launcher (a C program which loads the libjvm.so, calls JNI_CreateJavaVM to create the VM and so on). In that scenario, if the launcher installs its user signal handler before creating the Java VM, the Java VM will remember the user handlers and chain them behind their own signal handlers. 2) if the user native code is loaded after the Java VM is created, this does not work. The libjsig.so is the answer for this problem: it replaces the system signal APIs (sigaction() etc) with its own versions, and any user code attempting to install a signal handler will not replace the global signal handler but the user handler will be chained behind the (already installed) Java VM signal handler.

In order to make (2) to work, one must load libjsig.so with LD_PRELOAD before starting the VM:

example: LD_PRELOAD=//jre/lib/amd64/libjsig.so java myprogram

Answer 2

As your question seemed intriguing, I took a fast google search and found that page concerning JNA. To quote it

VM Crash Protection

It is not uncommon when defining a new library and writing tests to encounter memory access errors which crash the VM. These are often caused by improper mappings or invalid arguments passed to the native library. To generate Java errors instead of crashing the VM, call Native.setProtected(true). Not all platforms support this protection; if not, the value of Native.isProtected() will remain false. NOTE: When protected mode is enabled, you should make use of the jsig library, if available (see Signal Chaining) to avoid interfering with the JVM's use of signals. In short, set the environment variable LD_PRELOAD (or LD_PRELOAD_64) to the path to libjsig.so in your JRE lib directory (usually ${java.home}/lib/${os.arch}/libjsig.so) before launching your Java application.

So, from what I guess, the jsig library should be available "somewhere" in your Java installation directory.

Answer 3

The jsig library does signal chaining, allowing signals to be passed to the JVM. See this from IBM

This is important, as from my understanding of the JVM, it uses the SIGSEGV signal to determine if you're dereferencing a null pointer, and if you are it will throw a NullPointerException.

Unfortunately, I can never remember where I got a copy of libjsig.so from, but you should be able to get it from some Red Hat or Debian source.