JDK-8292695 : SIGQUIT and jcmd attaching mechanism does not work with signal chaining library
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17.0.3,19,20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-08-20
  • Updated: 2024-01-24
  • Resolved: 2022-09-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 19 JDK 20 JDK 8
11.0.18-oracleFixed 17.0.6-oracleFixed 19.0.2Fixed 20 b15Fixed 8u351Fixed
Related Reports
Relates :  
Relates :  
Description
After JDK-8279124, sending SIGQUIT to get thread dumps and using jcmd to attach a running Java process stopped working if signal chaining library (libjsig.so) is enabled. See https://docs.oracle.com/en/java/javase/17/troubleshoot/handle-signals-and-exceptions.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D for more about signal chaining.

According to test/hotspot/jtreg/runtime/signal/README, SIGQUIT does not support chaining. After JDK-8279124, the JVM calls sigaction() twice to set two different handlers for SIGQUIT. The first time it sets the handler within the window bounded by libjsig's JVM_begin_signal_setting() and JVM_end_signal_setting(), but the window is intended for signals that support chaining. When the second time it calls os::signal() => sigaction(), the overridden sigaction() in jsig.c runs the following branch:
  if (jvm_signal_installed && sigused) {
    /* jvm has installed its signal handler for this signal. */
    /* Save the handler. Don't really install it. */
    if (oact != NULL) {
      *oact = sact[sig];
    }
    if (act != NULL) {
      sact[sig] = *act;
    }
    signal_unlock();
    return 0;
  }

As a result, the second time does not really install the UserHandler for SIGQUIT.

Context: Our Java applications almost always enable signal chaining. We have a customized launcher with logic to override sigaction() similarly to what libjsig.so does.

Reproducible steps:
$ LD_PRELOAD=<jdk_path>lib/server/libjsig.so <jdk_path>/bin/java -jar <application_jar>
$ kill -SIGQUIT <application_pid>
Expected: Thread dump is printed on stdout.
Actual: Nothing is printed.

Also "$ jcmd <application_pid>" gives an error:
2006627:
java.io.IOException: No such process
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.sendQuitTo(Native Method)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:83)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
Comments
Fix request [17u] I backport this for parity with 17.0.6-oracle. Low to medium risk, small change in os layer. Related issues: one is already in 17, the other is only loosely connected to this. I had to do some obvious resolves. Test passes. SAP nighlty testing passed.
03-11-2022

A pull request was submitted for review. URL: https://git.openjdk.org/jdk19u/pull/59 Date: 2022-10-29 06:28:08 +0000
29-10-2022

Fix request [19u] This backport fixes a bug in JDK 19 for applications that use signal chaining (libjsig.so). The change applies cleanly.
29-10-2022

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/834 Date: 2022-10-25 11:51:38 +0000
25-10-2022

Changeset: 45ff10cc Author: Man Cao <manc@openjdk.org> Date: 2022-09-09 19:12:08 +0000 URL: https://git.openjdk.org/jdk/commit/45ff10cc68296c7c73d0eafe6fcc9946ab98267e
09-09-2022

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/9955 Date: 2022-08-20 22:43:03 +0000
22-08-2022