Application crash without dump

Question

My application built in Java (uses multithreads) interacts with a server via CORBA interface. My application further interacts with another application built in Java. The flow is like this: The request to manage objects comes from a C++ application via CORBA calls to my application. Then my application interacts with another Java application to manage some stuff. The objects to be managed are loaded in memory and notifications are continously sent from the other Java application to my module and my module intern sends it to the C++ app via CORBA. Once I start the applications, after an hour, my application is crashed with no dump. The C++ application is up and running.
The environment is HP-UX Itanium. JDK used is 1.5.0_14. I checked with JConsole for memory and only 250 MB of 1 GB is used. No Perm space problems. More than half of it is empty. There is a script to start the C++ and Java applications. A watch dog always checks for the Java process and notifies the C++ app once it is down. Then the C++ app automatically starts the Java app. This is happening properly. Logs are not very informative even with DEBUG option. The question is how and why my java module is getting crashed. And as said there is no dump seen.
Please consider this as very high priority and any suggestions are most welcome.

Answer 1

First diagnose the problem.
But is there any way to know what is causing all the threads to exit?To guard against the VM exiting after all threads have exited, force a non-daemon thread that runs forever (a while(true) loop that outputs an "up and running" message for example).
I mean is it some kind of uncaught exception?Maybe, then make sure all your non-daemon threads have a proper exception handler at the top of the stack (setting an UncaughtExceptionhandler on all such threads does not prevent the exception, but at least would log it).
To diagnose if the VM exists due to a System.exit() call:
- (simple but non-guaranteed way) add a shutdownHook (see java.lang.Runtime.addShutdownHook(...)) that logs a statement when kicked in.
- (guaranteed but cumbersome) Put a java.lang.System class of your own in the bootclasspath, which logs the exit() call along with a stack trace, or simply refuses it.
- (guaranteed but requires delving in an area of the JVM I don't know) set a custom SecurityManager, or configure custom permissions, that deny any code the permission to execute System.exit() calls. Make sure you capture the corresponding SecurityException stack trace in the logs, you'll find the guilty call spot a couple of lines down the stack.
or platform problemIf no test above confirms any of the other possibilites... Then contact the JVM vendor, there may be more trace options than you know.