Since a couple of weeks the SWI-Prolog Java interface crashes immediately in JNI_CreateJavaVM. Well, on most machines. It runs fine on one of my machines, which runs the same version of Ubuntu and openjdk ... I stripped this down to this little program:
#include <jni.h>
#include <stdio.h>
#include <stdlib.h>
static JavaVM *jvm;
int
main(int argc, char **argv)
{ JavaVMInitArgs vm_args = {0};
JNIEnv *env;
JavaVMOption opt[8] = {0};
int optn = 0;
int r;
opt[optn++].optionString = "-Djava.class.path=" "jpl.jar:.";
opt[optn++].optionString = "-Xrs";
vm_args.version = JNI_VERSION_1_2;
vm_args.nOptions = optn;
vm_args.options = opt;
r = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
fprintf(stderr, "Got %d\n", r);
exit(0);
}
That is compiled using
JVM=/usr/lib/jvm/java-8-oracle
#JVM=/usr/lib/jvm/java-1.8.0-openjdk-amd64
gcc -I$JVM/include \
-I$JVM/include/linux \
-L$JVM/jre/lib/amd64/server \
-L$JVM/jre/lib/amd64 \
-g -Wall -o t t.c -ljsig -ljava -lverify -ljvm
Gdb gives no usable stack trace as it claims a stack corruption somewhere in the JVM. I'm pretty lost as this crashes both using Oracle and OpenJDK java one assumes it is my fault. On the other hand, this worked for years and is what you find in all examples as well.
Platform is Ubuntu 16.04, amd64, gcc 5.4.0
valgrind says this. Funny enough, it says the same on the machine where it runs without crashing.
==9642== Memcheck, a memory error detector
==9642== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9642== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==9642== Command: ./t
==9642==
==9642== Warning: set address range perms: large range [0x5cb200000, 0x7c0000000) (noaccess)
==9642== Warning: set address range perms: large range [0x5cb200000, 0x5e0100000) (defined)
==9642== Warning: set address range perms: large range [0x7c0000000, 0x800000000) (noaccess)
==9642== Invalid write of size 4
==9642== at 0x84C0BE7: ???
==9642== by 0x84AE4E6: ???
==9642== by 0x549C11A: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x545ABA6: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x545AFA1: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x545B3FF: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x545B1B1: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x545B3FF: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x584A9BB: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x54C31E1: JNI_CreateJavaVM (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==9642== by 0x4007C7: main (t.c:22)
==9642== Address 0xffeffea00 is on thread 1's stack
==9642== 4096 bytes below stack pointer
I suspect this problem is related to the following kernel issue https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772
I am noticing what I think is the same issue in CentOS 7 after updating to latest packages:
- java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64
- Linux 3.10.0-514-21.2.el7.x86_64
If I reboot with Linux 3.10.0-514-21.1 the problem goes away.