A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution. See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html . The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE. ------------- Commit messages: - tolerate sigaction failing - Fixes - fix - start+repro-case Changes: https://git.openjdk.org/jdk/pull/26615/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26615&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364611 Stats: 196 lines in 5 files changed: 195 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26615.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26615/head:pull/26615 PR: https://git.openjdk.org/jdk/pull/26615
