Java eqivalent of "abort" w/core dump?
This might be a FAQ; it it is, please point me to the answer. Meanwhile:
Is there a java equivalent to the Unix "abort" call? I guess what I really want to do is have my application serialize the whole java memory space into a file, then later use jdb or something similar to examine the file, look at threads and their local variables, etc. I need this because I have a server in C that I'm considering porting to Java. Using lots of asserts and core dumps has been invaluable in the C server; when it sees an error, it dumps core, then restarts. When I get a chance, I examine the core file to find the exact cause of the error. Thanks to this, a "crash" means a few minutes of downtime, but it's been getting steadily more reliable since 90% of the time I'm able to fix the bug from the data in the core dump. I know that in Java I can throw exceptions to get the stack trace of the thread that failed the assertion, but often I need more information than that; rummaging through the full application state at the moment of death is much more helpful than just a stack trace.
Does such a system exist? Is there a RFE for such a system? Maybe 3rd party support? I can't believe that I'm the only
[1222 byte] By [
wmshuba] at [2007-9-29 9:13:10]
[...]
> I know
> that in Java I can throw exceptions to get the stack
> trace of the thread that failed the assertion, but
> often I need more information than that; rummaging
> through the full application state at the moment of
> death is much more helpful than just a stack trace.
>
> Does such a system exist?
Yes.
> Is there a RFE for such a system?
See BugID 4593163
http://developer.java.sun.com/developer/bugParade/bugs/4593163.html
>Maybe 3rd party support?
That really depends on the JVM vendor for the platform
you are using. Decoding the bits in a core file requires
deep knowledge of the underlying program structure.
>I can't believe that I'm the only
Don't worry. You are not the only.;-)
The main issue is that taking a core dump at the OS level
captures raw bits representing the process executing a Java
Virtual Machine (JVM) at the instant it is running your Java
Language Program as data. In the past it took a JVM wizard
to piece together the clues that would allow you to tell what
bytecode or method was executing inside the JVM, inside the
core file.
As described in a talk at the last JavaOne conference:
Experimental Tools for Serviceability TS-3280
http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/3280.pdf
serviceability is an important feature of the upcoming release.
4593163 is part of the effort to help out in this area.
Thanks for your answer. I checked, the RFE has no votes. Well, now it has one - mine.
It seems that we don't really need an OS-level core dump though. What if the JRE wrote *all* objects out to a file (the format could be straightforward - just the class, an object ID, and the values of all member variables), and dump all stack frames too (each with a list of the local variables). From that, jdb could simply read all that in; then I could ask, "for the thread named foo, show me this object...or that object...etc."
Anyway, just a thought. It seems that it would be much easier than OS-level core dumps, because then the "java core" wouldn't have any data specific to the OS or to the JVM; just the objects and stack frames.
