Bug #21999: Sometimes getting segfault and sometimes getting a "Floating point exception" when running some ractor code involving BigDecimal

• Status: Open
• Assignee: -
• Target version: -
• ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-linux]
• Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN

[miles-georgi (Miles Georgi)]

Hey hey!

I don't know if this might be a duplicate of https://bugs.ruby-lang.org/issues/21992 as the code involves two subclasses of BasicObject that have #initialize methods defined. Apologies if a dup of that! I'm not sure how best to run this against the current tip of ruby but am happy to try that if somebody can point me to how to do it.

When running the script here: https://github.com/ractor-shack/ractorize/blob/main/example_scripts/product-benchmark-segfault

I sometimes see a segfault and sometimes I get a "Floating point exception.

This does use "bigdecimal" so not sure if the bug might be there.

To reproduce, you could clone that repo, go into the example-scripts directory, bundle install, and ./product-benchmark-segfault

You might have to run it a few times to see the various bad outcomes.

Using 4.0.2 on a debian trixie machine with ruby installed via rbenv.

I'll attach some output text.

segfault2.txt happens sometimes and has tons of info.

This also happens if using path: ".." to point it at the local files instead of the installed gem.

I do know C and could attempt to help with this sort of thing. Though, somebody would likely have to be interested in pairing with me to help me ramp up on how to debug a project like MRI.

Cheers!

[miles-georgi (Miles Georgi)]

• ruby -v changed from 4.0.2 to ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-linux]

[miles-georgi (Miles Georgi)]

I also tried this with 4.1-dev and it had the same behavior: ruby 4.1.0dev (2026-04-14T21:04:52Z master edb95b13a3) +PRISM [x86_64-linux]

[tompng (tomoya ishida)]

Shorter reproduction code:

require 'bigdecimal'
4.times.map do
  Ractor.new do
    loop { raise unless BigDecimal(3.14) }
  end
end
sleep 1
GC.start

I guess this is a bug of BigDecimal's float parsing logic. If the float value is changed to 314.0, it won't crash.
I've filed an issue to ruby/bigdecimal https://github.com/ruby/bigdecimal/issues/527