Signal.trap with numeric USR1 value traps SIGBUS on Linux #9510

Description

On JRuby/Linux, passing the numeric value returned by Signal.list.fetch("USR1") back to Signal.trap appears to trap SIGBUS instead of SIGUSR1. Since SIGBUS is reserved by the JVM, this raises ArgumentError: can't trap reserved signal: SIGBUS.

The same round trip works on CRuby, and Signal.trap("USR1", ...) works on JRuby.

Minimal reproduction

name = "USR1"
number = Signal.list.fetch(name)

puts "ruby: #{RUBY_DESCRIPTION}"
puts "Signal.list[#{name.inspect}] = #{number}"

Signal.trap(name, "IGNORE")
puts "Signal.trap(#{name.inspect}, "IGNORE") succeeded"
Signal.trap(name, "DEFAULT")

Signal.trap(number, "IGNORE")
puts "Signal.trap(#{number.inspect}, "IGNORE") succeeded"
Signal.trap(number, "DEFAULT")

Expected behavior

Signal.trap(Signal.list.fetch("USR1"), "IGNORE") should behave the same as Signal.trap("USR1", "IGNORE"), or at least trap the signal represented by Signal.list.

Actual behavior

In GitHub Actions on Ubuntu with JRuby 10.1.0.0, code which does this normalization fails with:

ArgumentError: can't trap reserved signal: SIGBUS
  <internal:uri:classloader:/jruby/kernel/signal.rb>:21:in `trap'

The failing project normalized :USR1 to Signal.list.fetch("USR1") and then called Signal.trap(number, "IGNORE"). On Linux, USR1 is signal number 10, but JRuby appears to resolve numeric 10 as SIGBUS rather than SIGUSR1.

CI run with failure context: https://github.com/socketry/async-signals/actions/runs/28289947798/job/83820135475

Environment

Observed in GitHub Actions:

Ubuntu 24.04
jruby 10.1.0.0 (4.0.0) 2026-04-20 32f988b78c OpenJDK 64-Bit Server VM 21.0.11+10-LTS on 21.0.11+10-LTS +indy +jit [x86_64-linux]

Local macOS contrast using the same script:

jruby 10.1.0.0 (4.0.0) 2026-04-20 32f988b78c OpenJDK 64-Bit Server VM 21.0.11 on 21.0.11 +indy +jit [arm64-darwin]
Signal.list["USR1"] = 30
Signal.trap("USR1", "IGNORE") succeeded
Signal.trap(30, "IGNORE") succeeded

CRuby on macOS also accepts the numeric round trip.