On 12/07/2019 11:21, Rémy Maucherat wrote: > On Thu, Jul 11, 2019 at 11:01 PM Rainer Jung <rainer.j...@kippdata.de > <mailto: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> > > <mailto: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 >
I also have the same core using the AprConnector I can't really see what is wrong there. gdb doesn't really help :-( I have replaced the apr_snprintf by snprintf and I also have a core: +++ Thread 19 "apr-8443-exec-1" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffaffff700 (LWP 24724)] 0x00007ffff792e41a in __GI___printf_fp_l (fp=<optimized out>, loc=<optimized out>, info=<optimized out>, args=<optimized out>) at ../include/ctype.h:53 53 return __libc_tsd_address (const int32_t *, CTYPE_TOLOWER); Missing separate debuginfos, use: dnf debuginfo-install sssd-client-2.2.0-3.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64 (gdb) bt #0 0x00007ffff792e41a in __GI___printf_fp_l (fp=<optimized out>, loc=<optimized out>, info=<optimized out>, args=<optimized out>) at ../include/ctype.h:53 #1 0x00007ffff7946f71 in __vfprintf_internal (s=0x7fffafffe660, format=0x7ffff7ff05f7 "%.0f", ap=0x7fffafffe7e0, mode_flags=<optimized out>) at vfprintf-internal.c:1644 #2 0x00007ffff7959f8a in __vsnprintf_internal (string=0x7ffff7ffa2a0 <buf> "", maxlen=<optimized out>, format=0x7ffff7ff05f7 "%.0f", args=0x7fffafffe7e0, mode_flags=0) at vsnprintf.c:114 #3 0x00007ffff7933386 in __GI___snprintf (s=<optimized out>, maxlen=<optimized out>, format=<optimized out>) at snprintf.c:31 #4 0x00007ffff7fe6ea4 in ssl_rand_choosenum (l=0, h=127) at src/ssl.c:720 +++ Suggestions? -- Cheers Jean-Frederic --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
