On Mon, 17 Jan 2022 09:52:04 GMT, Thomas Stuefe <stu...@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
