RFR: 8020962: dump loaded java classes when vm crash

[Christian Tornqvist]

Hi Yumin,

The idea is to do as little as possible in the VM error handler, since we've crashed for some reason we don't know what state the process is in and we have to be extremely careful in when we're gathering the information. This seems like a step that is risky for all of the reasons David mentioned below.

It's also information that can easily be extracted post-mortem from the core/mdmp using the method you described for OSX, so gathering this at the time of a crash seems like an unnecessary risk.

Thanks,
Christian

-----Original Message-----
From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Monday, August 12, 2013 1:56 AM
To: Yumin Qi
Cc: hotspot compiler; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8020962: dump loaded java classes when vm crash

Hi Yumin,

Note that the SA is only present in a full JDK, not a JRE (full or compact profile).

I have quite a few concerns with this:

We already do a lot of things that are not valid to be done from a signal handling context but this really takes that to an extreme. Doing fork-exec from a signal handler seems like a recipe for disaster (Note the existing onError facility is typically used for synchronous failures.)

The idea of launching a second VM to try and query a VM that has crashed also seems somewhat problematic:
- What mechanism will the SA try to use to query the VM?
- What if the state of the crashed VM stops the SA from being able to attach properly (ie both processes hang)?
- What if it the SA also crashes, will it launch a third VM then a fourth etc?

Also what is the nature of this dump? How big is it? Where will it go?

Thanks,
David

On 12/08/2013 9:36 AM, Yumin Qi wrote:
> Hi, all
>
>    I would like to have your review for
>
> http://cr.openjdk.java.net/~minqi/8020962/webrev0/
> <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/>
>
> Description: When JVM crashed, we also want to check the application 
> class files especially we got core file from customers.  The aftermath 
> analysis will benefit from all loaded java classes available. In this 
> change, spawn another process running SA to do the job when JVM 
> crashes, this way also avoid further messing up with the error report 
> which already in signal handler.
>
> Note: The test has done with following two bugs worked around:
>    8022655: ClassDump ignored jarStream setting (This will be fixed 
> and integrated by Kevin Walls soon)
>    8011888: sa.js: TypeError: [object JSAdapter] has no such function 
> "__has__" (Not know when it will be integrated)
>    That is, without those two fixed, the jars of loaded classes will 
> not be successfully dumped.
>    Also, on MacOS it requires security access permission to attach to 
> another process, so omit doing so. To get loaded jar file s, with core 
> file available (on all platforms), one can (only after this
> change) do
>
>    $JAVA_HOME/bin/java [-d64] -cp $JAVA_HOME/lib/sa-jdi.jar 
> sun.jvm.hotspot.DumpLoadedClasses $JAVA_HOME/bin/java corefile
>
>
> Thanks
> Yumin