Segmentation Fault in java

Question

Hi,
We have a C program which creates JVM and invokes java methods of a wrapper class. The wrapper class invokes a method on EJB (stateless session bean) and the bean is protected and authorization is delegated to a Security component. (a separate java component) . We authenticate to the Security Component and get the ticket and pass it while creating the javax.naming.InitialContext. Then lookup the bean and invoke the methods.
The C process is a record processing system. It runs continuously. It sleeps till it receives records. For each record, the bean method is invoked to fetch information.
Suppose we get a record for processing at Time X. It is processed correctly.
At time X + <1 hour> (assume that session with security component timesout ). So the bean call fails with AccessException. When we try to recreate the session and reinitialize context. Sometimes, it runs fine. Sometimes it crashes with Signal 11 and dumps core.
When we look at the core using dbx,
a) "where" command does not show the java class stack trace.
It shows some addresses. Not the exact class names and methods. So we are not able to debug it
b) the hs_..log file generated by java at crash time.. has only the last call. It does not include the stack trace.
I am on solaris and running java 1.4.2_06.
Please let me know if somebody has any idea on what is going on.
why does not dbx display the java stack trace (compiled java code runs.. why does not dbx unwind java stack trace ) ?

Answer 1

Thanks for your help.
I forgot to watch the topic. So did not reply back.
Java on HP provides unwind shared library so that gdb can show the java stack trace. I thought dbx will show it by default.
The EJB is not removed. I will try it with check:jni and PrintCompilation -- PrintCompilation does not help much i guess as it is not crashing during compilation. The trace does not show that.. The crash is happening in jit compiled java code ..
Will give it a try.
pstack also shows the same as dbx does. We installed signal handlers .. if we use them, the jvm signal handler delegates to my signal handler and it does not generate the hs_err*.log .. So we disabled our signal handler .. so jvm prints the hs_err*log and this log is supposed to show the java stack trace but as memory is corrupted it is not able to .. this is what i think ..