Am 11.07.2019 um 22:10 schrieb Rémy Maucherat:
On Thu, Jul 11, 2019 at 8:42 PM Rainer Jung <rainer.j...@kippdata.de
<mailto:rainer.j...@kippdata.de>> wrote:
Hi Rémy,
When one looks up the macros in native/include/tcn.h, this boils
down to
the following returning null:
(*env)->FindClass(env, "org/apache/tomcat/jni/FileInfo")
So our own FileInfo class can not be found. FindClass docs indicate its
searched in the CLASSPATH although I'm not sure whether its really the
classpath or some search paths of a class loader hierarchy.
You might want to add the JVM commandline flag "-verbose:class" for any
easy way to track class loading.
I didn't really grok what you meant with "define in JNI configuration".
For normal JVMs the code just works, so what might be special for Graal
that org.apache.tomcat.jni.FileInfo can't be found?
A Graal native image is indeed not a normal JVM and does not support any
kind of dynamic class loading, it has to be declared first in these
configuration files.
Ah OK.
So I am adding this to the jni one:
{ "name":"org.apache.tomcat.jni.FileInfo" },
{ "name":"org.apache.tomcat.jni.Sockaddr" },
{ "name":"org.apache.tomcat.jni.FileInfo" },
Again FileInfo? I think instead "org.apache.tomcat.jni.Error" should be
the third one.
{ "name":"java.lang.String", "methods" :
[{"name":"<init>","parameterTypes":["byte[]"]},{"name":"getBytes","parameterTypes":[]}]
}
And loading now works.
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
lifecycleEvent
INFO: Loaded APR based Apache Tomcat Native library [1.2.23] using APR
version [1.6.5].
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
lifecycleEvent
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters
[false], random [true].
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
lifecycleEvent
INFO: APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
initializeSSL
INFO: OpenSSL successfully initialized [OpenSSL 1.1.1c FIPS 28 May 2019]
However when trying to actually connect I got:
Segmentation fault (core dumped)
Oops.
If the above duplicate class was just a copy and paste typo, but you had
it right in your actual work, the next one could try, would be
activating writing core dumps in the underlying OS. The resulting core
should be inspectable depending on OS via gdb or similar tools. The
simplest gdb invocation would be
gdb /path/to/my/bin/java /path/to/my/corefile
and then at the gdb prompt the command
bt
or
bt full
or
thread apply all bt
or
thread apply all bt full
That way we should at least see, in which function the crash happens.
Depending on symbols etc. you might even get line numbers.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
