RFR: 8279124: VirtualMachineImpl should check signal handler has installed before sending SIGQUIT

[Xin Liu]

On Mon, 17 Jan 2022 09:52:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> I propose a simpler and more robust way to fix it though
>> 
>> Great, this is the kind of thing I was heading towards with the conversation in the bug text.  Although not sure why I could not reproduce the problem, with various different JDK versions.
>
>> > I propose a simpler and more robust way to fix it though
>> 
>> Great, this is the kind of thing I was heading towards with the conversation in the bug text. Although not sure why I could not reproduce the problem, with various different JDK versions.
> 
> Ah, I missed your conversation.
> 
> I reproduced this by adding a delay during initialization and sending sigquit manually. The bug is not restricted to jcmd, sigquit handling is broken during initialization. Folks tend to send sigquit to unresponsive VMs to get thread dumps, so coring is unfortunate (another reason not to fix it in jcmd itself).
> 
> Cheers, Thomas

hi, @tstuefe @dholmes-ora 
I think your opinion is same.  I agree Thomas's approach is more general.  It works in practice because "making the window during which SIGQUIT terminates the VM process small enough to be unhittable". The gain is obvious. It can work on all POSIX systems and the attach clients don't need to be patched. 

One behavior change in the 2f25753 is that we can't core the JVM process with -Xrs (ReduceSignalUsage) anymore  SIGQUIT will be intercepted by JVM_HANDLE_XXX_SIGNAL. Thomas said this is fine.
--lx

-------------

PR: https://git.openjdk.java.net/jdk/pull/7003