> 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.

Thomas Stuefe has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains seven commits:

 - merge
 - fix comments about closeDescriptors
 - Feedback Roger
 - 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=03
  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

Reply via email to