RFR: 8279124: VM does not handle SIGQUIT during initialization [v3]

[Xin Liu]

On Wed, 19 Jan 2022 12:39:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only install JVM_HANDLE_XXX_SIGNAL when ReduceSignalUsage is
>>   false(default value).
>>   
>>   This patch also adds a log message with 'os+init=info'.
>
> Hi -- thanks for updating the bug title and text.  Yes it's much better to start with a concise problem description.  I'm in favour of the signal hander change.  I'm not personally concerned about printing, silently handling SIGQUIT seems fine for a VM at this stage, perhaps printing just adds risk.
> 
> Still curious that I don't reproduce the problem by making heap initialization slow with options like -Xms100g -XX:+AlwaysPreTouch as you could.  Startup can be so slow I can attach gdb and see it's in:
> 
> Threads::create_vm / init_globals /  universe_init / G1CollectedHeap::initialize / ...etc...
> 
> ...but jcmd or kill -QUIT don't hurt my JVM. 8-)
> 
> That process' /proc/PID/status contains:
> 
> SigIgn: 0000000000000006
> SigCgt: 0000000180000000
> 
> ...so that I think has signals 2 and 3 ignored? (Ubuntu)
> 
> Elsewhere I used Oracle Linux under Windows Services for Linux, and SigXXX fields in /proc/PID/status are all zeroes, not sure if they are meaningful there.  Possibly another reason to handle this with the signal handler change.
> 
> On a real OracleLinux install I do see :
> 
> SigIgn: 0000000000000006
> SigCgt: 0000000000000000
> 
> at startup become:
> 
> SigIgn: 0000000000000006
> SigCgt: 0000000181001cc8
> 
> ..after some seconds.  But I still can't trigger the issue, there are some signals ignored there also.
> 
> So I like the change but would like to be clearer where the problem exists, where (what platforms?) can we see no signals ignored or caught at startup, and trigger the problem of crashing the VM with SIGQUIT.

hi, @kevinjwalls, 
Even though AlwaysPreTouch leverages multicore now, we can use "-XX:ParallelGCThreads=1" to restrict one parallel work to pretouch work. I think the reason you can't reproduce this because of "SigIgn: 0000000000000006". 

According to [signal(7)](https://man7.org/linux/man-pages/man7/signal.7.html), the default disposition of SIGQUIT(3) is "Core" and SIGINT(2) is "Term".  "SigIgn: 0000000000000006" indicates that you "Ign" them in the first place. Besides launcher and hotspot, is it possible systemd/bash or kernel can change it? 

The doc also describes as follows. Is that possible that you just fork but not exec so it just inherits the signal dispositions from your bash? 
> A child created via fork(2) inherits a copy of its parent's
  signal dispositions.  During an execve(2), the dispositions of
  handled signals are reset to the default; the dispositions of
  ignored signals are left unchanged.

--lx

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

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