Probably not very helup, but to make sure, the GetEnv is failing, I
would add a little code to native/src/jnilib.c in JNI_OnLoad() that
creates an observable side effect while executing int he function. E.g.
on Unix/Linux you could add something like
#include <stdio.h>
...
FILE *fd = fopen("/tmp/mytrace", "w");
int fputs("At step 1", fd);
int fflush(fd);
...
int fputs("At step 2", fd);
int fflush(fd);
...
int fputs("At step N", fd);
int fflush(fd);
int fclose(fd);
Sure poor man's tacing, but it will show, how for you get through
JNI_OnLoad() before it is returning.
Sorry for not being more helpful,
Rainer
Am 11.07.2019 um 10:59 schrieb Rémy Maucherat:
On Thu, Jul 11, 2019 at 9:18 AM Rainer Jung <rainer.j...@kippdata.de
<mailto:rainer.j...@kippdata.de>> wrote:
Hi Rémy,
for which Java version and distribution is this? The docs for Java 7
and
8 are much less precise about return codes than the cited docs for Java
9. So older versions might give a generic error. The used code for
checking versions is in the HotSpot sources for version 8 inside
hotspot/src/share/vm/runtime/thread.cpp (functions
Threads::is_supported_jni_version_including_1_1 and
Threads::is_supported_jni_version):
jboolean Threads::is_supported_jni_version_including_1_1(jint version) {
if (version == JNI_VERSION_1_1) return JNI_TRUE;
return is_supported_jni_version(version);
}
It is called from hotspot/src/share/vm/prims/jni.cpp in jni_GetEnv().
I don't see a code path returning -1 in the version I am looking at
(outdated Java 8 source code).
What is rather special about that environment w.r.t. platform/JVM/Arch
or so?
The environment is a Graal native image, built on the same machine.
https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.jni/src/com/oracle/svm/jni/JNILibraryLoadFeature.java#L87
So the OnLoad of tomcat-native seems to be invoked successfully, but
returns -1 signifying an error. I have no idea what the error really is.
Overall, I'm having TLS problems: the SunEC library (non) packaging is a
problem, there's no ALPN with JSSE, and tomcat-native doesn't work.
However, the rest works as I expected.
Rémy
Regards,
Rainer
Am 10.07.2019 um 20:42 schrieb Rémy Maucherat:
> Hi,
>
> I'm a bit stumped there, as I'm trying to get native to work in that
> rather special environment.
>
> JNI_OnLoad fails with:
> WARNING: The APR based Apache Tomcat Native library failed to
load. The
> error reported was [Unsupported JNI version 0xffffffff, required by
> bin/libtcnative-1.so.0.2.23]
> java.lang.UnsatisfiedLinkError: Unsupported JNI version 0xffffffff,
> required by bin/libtcnative-1.so.0.2.23
> at
>
com.oracle.svm.jni.JNILibraryInitializer.initialize(JNILibraryLoadFeature.java:87)
> at
>
com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibrary0(NativeLibrarySupport.java:153)
> at
>
com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibrary(NativeLibrarySupport.java:98)
> at
java.lang.ClassLoader.loadLibrary(Target_java_lang_ClassLoader.java:126)
> at java.lang.Runtime.load0(Runtime.java:809)
> at java.lang.Runtime.load(Runtime.java:241)
> at java.lang.System.load(System.java:366)
> at org.apache.tomcat.jni.Library.<init>(Library.java:42)
>
> Although this looks weird, this is actually returning -1 and it's
normal
> when it fails [it's a bad error message]. Most likely this
doesn't work:
> if ((*vm)->GetEnv(vm, &ppe, JNI_VERSION_1_4)) {
> return JNI_ERR;
> }
>
> Any ideas ?
>
> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
<mailto:dev-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: dev-h...@tomcat.apache.org
<mailto:dev-h...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
