tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Williams" <ccwillia...@ntlworld.com>
Subject Re: Tomcat and native libs.
Date Fri, 19 Sep 2003 10:16:29 GMT
I'm no Unix expert, but I believe that signal 11 is a segmentation fault
(i.e. you're accessing either an invalid memory address or one which you are
not allowed to use).  The most likely cause is a NULL pointer access.  What
you could try doing is handling signal 11 in your code.  In the remainder of
your native code you could set a global variable to the name of the current
function being executed and your signal handler could print this to STDOUT.
Then at least you can start to isolate where the problem is occurring.

Do something like the following:

#include <signal.h>
#include <siginfo.h>

char *g_currFn = "";

if (SIG_ERR == sigset(11, handler)) {
    // Bummer...
}
...

void handler(int sig) {
    // Print signal and offending function to STDERR
    psignal(sig, (const char *) g_currFn);
}

int myfunc(int) {
    g_currFn = "myfunc";
    ...
}


Something that is eminently possible is that your native code is relying on
a Java class that is, say, in $JAVA_HOME/jre/lib/ext and is being loaded by
the standard Java classloader but is not being loaded by the Tomcat loader.
In this case the call:
jclass clz = env->FindClass("example/somewhere/something/ClassIWant");
jmethodID mid = env->GetMethodID(clz, "<init>", "()V");

will access an invalid pointer and crash the virtual machine.  I know; I've
done it.

Hope this helps.

Chris.



Mime
View raw message