We have recently ported our C++ application from Solaris Sparc to Linux. The application uses JNI to access a third party java-based tool. The application runs fine on Solaris bu on Linux we get a SIGSEGV. The interesting part is that when we run a large volume of requests through and keep the process busy it works fine. As soon as we give it a little "break" and then submit another requests it crashes in libjvm with the call stack as below. Would it have something to do with garbage collection? Our application is 64 bit ans uses 64 bit JNI libraries. We are using Java 1.6 U26.

In C++ is relatively easy to write code which happens to work, but contains a bug never the less.

If the JVM fails only when you load your JNI, it is because the JNI is corrupting the memory.
It could be incorrectly handling Java Objects in a way which doesn't cause a problem on Solaris but does break on Linux x64. I would review how Objects are handled in the JNI layer.

Thanks everyone. You guys pushed me to do my homework and do some heavy debugging. First I found the -Xcheck:jni option very useful.
I turns out quite a few things were wrong:
1. One static method was being invoked as member method, not static:
JNIEnv::CallLongMethod instead of JNIEnv::CallStaticLongMethod. Note that the program seemed to work just fine unil I turned on JNI checking.
2. The java class handles were not globalized even though they were invoked from different threads and from different procedures after the procedure that obtained the handel has exited. The solution was to "globalize" the handle before saving it off:

4. And finally, a multithreading issue. The java methods were being called from different threads. The application was coded in an attempt to handle that by calling
JavaVM->AttachCurrentThread((void **)&mpoJNI_ENV, NULL)
The problem was, detecting whether we were dealing with a new thread or not. Since the threads are being created completely outside our control in the middleware layer( Orbix, to be precise) we'd save and compare the thread IDs. The problem is, on linux, pthread_self() seems to always return the same ID even though we were dealing with an entirely different thread! We used linux-specific gettid() instead and it worked! The app stopped crashing and JNI check stopped complaining.