On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> 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. src/java.base/unix/native/libjava/childproc.c line 429: > 427: } > 428: > 429: // Childs should be started with default signal disposition for > SIGPIPE Editorial: "Childs" -> Children for plural, "Child" for singular. Here and in tests. test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c line 60: > 58: struct sigaction act; > 59: if (sigaction(signals[n].sig, NULL, &act) != 0) { > 60: perror("sigaction"); The sigaction error message goes to stderr, so it is does not appear in line with the signal name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2257297399 PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2257335209
