On Thu, Jul 11, 2019 at 11:01 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
> 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. > In the native code, it crashes on: https://github.com/apache/tomcat-native/blob/master/native/src/ssl.c#L635 I modified the code to: double d = (((double)(rand()%RAND_MAX)/RAND_MAX)*(h-l)); apr_snprintf(buf, sizeof(buf), "%.0f", d); And it cores on the apr_snprintf. I don't see how it is unsafe though. Rémy
