Garbage Collector tuning

[javaOrC]

I am not using JNI. I don't know why libc is involved.
I am using 3rd party tool called JCS.(cache). Probably that's using libc.
I can try an alternative for that.

[Tolls]

That SIGSEGV (Oxb) is almost always a result of some JNI code.

[javaOrC]

I have some 3rd party apps(jar files) and since my code doesn't use JNI explicitly, one of the 3rd party tools should be using.

Is there any tool which tells me who is using libc in my application?
Something like what ldd does for a binary.

[toadaly]

You could locate the shared objects used by your 3rd party product and examine the symbols in it. But that doesn't really tell you much, because even if your 3rd party native code doesn't depend directly on libc, it can still cause a stacktrace with libc in it, since the JVM uses libc.

[toadaly]

It just occured to me that I've seen this type of problem also when you have multiple versions of java installed and the library path is set up wrong such that you're using a JVM from one version and load libraries from another java version. You might want to check for that possibility.

[javaOrC]

Thanks,
I confirmed from both: hs_err_pid.log file generated upon crash and jconsole summary details that the libraries used are from jdk1.6.0-24 only.