JDK-8291569 : Consider removing JNI checks for signals SIGPIPE and SIGXFSZ
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-07-29
  • Updated: 2022-08-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 20
20Unresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
If -XX:+CheckJNICall is specified then the JVM checks (see os::run_peridoc_checks) if its signal handlers have been overridden for multiple signals, including SIGPIPE and SIGXFSZ.  Since the JVM ignores SIGPIPE or SIGXFSZ the checks for these signals can possibly be removed.

The signals are currently ignored by this code in signals_posix.cpp:

  // Ignore SIGPIPE and SIGXFSZ (4229104, 6499219).
  if (!signal_was_handled &&
      (sig == SIGPIPE || sig == SIGXFSZ)) {
    PosixSignals::chained_handler(sig, info, ucVoid);
    signal_was_handled = true; // unconditionally.
  }


Comments
Note that earlier in signals_posix.cpp it states: // Note: it's not uncommon that JNI code uses signal/sigset to install, // then restore certain signal handler (e.g. to temporarily block SIGPIPE, // or have a SIGILL handler when detecting CPU type). so we already acknowledge that JNI code may need to adjust the handling of SIGPIPE, so issuing a warning when we actually detect that seems somewhat pointless.
31-07-2022