- ruby-core - ml.ruby-lang.org

[ruby-core:117392] [Ruby master Feature#20405] Inline comments
by nobu (Nobuyoshi Nakada) 08 Jul '25

08 Jul '25

Issue #20405 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #20405: Inline comments https://bugs.ruby-lang.org/issues/20405 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose a new inline comment syntax. ```ruby p (| This is a comment (| and nested one |) /:|) (:|) #=> :| ``` -- https://bugs.ruby-lang.org/

7 10

[ruby-core:122659] [Ruby Bug#21502] Segfault with 3.2.8 with frida gem
by MatzFan (Brian Cohen) 06 Jul '25

06 Jul '25

Issue #21502 has been reported by MatzFan (Brian Cohen). ---------------------------------------- Bug #21502: Segfault with 3.2.8 with frida gem https://bugs.ruby-lang.org/issues/21502 * Author: MatzFan (Brian Cohen) * Status: Open * ruby -v: 3.2.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've just seen a segfault executing the following code in irb with the frida gem: ``` shell $ rbenv versions * 3.2.8 (set by /home/me/.rbenv/version) $ gem install frida Fetching frida-0.1.1.gem Building native extensions. This could take a while... frida has been successfully compiled and installed, frida-core is no longer required and can be safely removed. Successfully installed frida-0.1.1 1 gem installed $ irb irb(main):001:0> require 'frida' => true irb(main):002:0> mgr = Frida::DeviceManager.new => #<CFrida::DeviceManager:0x00007fd91dbf49a8> irb(main):003:0> devices = mgr.enumerate_devices => [#<Device: id="local", name="Local System", type="local">, ... irb(main):004:0> device = devices.last => #<Device: id="emulator-5554", name="Android Emulator 5554", type="usb"> irb(main):005:0> device.is_lost => false irb(main):006:0> device.enumerate_applications (irb):6: [BUG] Segmentation fault at 0x0000000000020000 ... see attached backtrace ``` Happy to provide more information about my system setup if required. ---Files-------------------------------- segfault_3.2.8 (46.7 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122652] [Ruby Bug#18940] Ruby Ractor fails with IOError when handling higher concurrency
by jhawthorn (John Hawthorn) 04 Jul '25

04 Jul '25

Issue #18940 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed This doesn't reproduce on my machine on 3.5dev, and there have been a number of improvements to Ractors likely to have solved this. Please reopen if that's not the case :) ---------------------------------------- Bug #18940: Ruby Ractor fails with IOError when handling higher concurrency https://bugs.ruby-lang.org/issues/18940#change-113932 * Author: brodock (Gabriel Mazetto) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.2.0dev (2022-07-26T16:40:03Z master 3b1ed03d8c) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Reproduction server: ``` require 'socket' # Set based on CPU count CONCURRENCY = 8 server = TCPServer.new(8080) workers = CONCURRENCY.times.map do Ractor.new do loop do # receive TCPSocket session = Ractor.recv request = session.gets puts request session.print "HTTP/1.1 200\r\n" session.print "Content-Type: text/html\r\n" session.print "\r\n" session.print "Hello world! Current time is #{Time.now}" session.close end end end loop do conn, _ = server.accept # pass TCPSocket to one of the workers workers.sample.send(conn, move: true) end ``` run apache benchmark against code above: ``` ab -n 20000 -c 20 http://localhost:8080/ ``` or run using hey (https://github.com/rakyll/hey) ``` hey -n 20000 -c 20 http://localhost:8080/ ``` you should see something like this on the benchmark tool side: ``` Summary: Total: 32.9538 secs Slowest: 2.6317 secs Fastest: 0.0002 secs Average: 0.0331 secs Requests/sec: 606.9098 Response time histogram: 0.000 [1] | 0.263 [16968] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 0.527 [1740] |■■■■ 0.790 [0] | 1.053 [0] | 1.316 [0] | 1.579 [0] | 1.842 [0] | 2.105 [20] | 2.369 [0] | 2.632 [6] | Latency distribution: 10% in 0.0008 secs 25% in 0.0010 secs 50% in 0.0012 secs 75% in 0.0016 secs 90% in 0.0075 secs 95% in 0.3101 secs 99% in 0.3175 secs Details (average, fastest, slowest): DNS+dialup: 0.0322 secs, 0.0002 secs, 2.6317 secs DNS-lookup: 0.0006 secs, 0.0000 secs, 0.0127 secs req write: 0.0001 secs, 0.0000 secs, 0.0095 secs resp wait: 0.0007 secs, 0.0000 secs, 0.0140 secs resp read: 0.0001 secs, 0.0000 secs, 0.0088 secs Status code distribution: [200] 18735 responses Error distribution: [1231] Get "http://localhost:8080/": dial tcp [::1]:8080: connect: connection refused [16] Get "http://localhost:8080/": dial tcp [::1]:8080: connect: connection reset by peer [1] Get "http://localhost:8080/": net/http: HTTP/1.x transport connection broken: unexpected EOF [1] Get "http://localhost:8080/": read tcp 127.0.0.1:57078->127.0.0.1:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57054->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57058->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57059->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57062->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57067->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57068->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57069->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57070->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57071->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57072->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57075->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57076->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57087->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57088->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57089->[::1]:8080: read: connection reset by peer [1] Get "http://localhost:8080/": read tcp [::1]:57090->[::1]:8080: read: connection reset by peer ``` and this on the ruby process: ``` ... GET / HTTP/1.1 GET / HTTP/1.1 #<Thread:0x0000000100fbf6e8 run> terminated with exception (report_on_exception is true): ractor.rb:21:in `write': GET / HTTP/1.1 uninitialized stream (IOError) from ractor.rb:21:in `print' from ractor.rb:21:in `block (3 levels) in <main>' from ractor.rb:11:in `loop' from ractor.rb:11:in `block (2 levels) in <main>' GET / HTTP/1.1 GET / HTTP/1.1 ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122648] [Ruby Bug#21499] make install - power_assert is a runtime_dependency of test-unit
by MSP-Greg (Greg L) 03 Jul '25

03 Jul '25

Issue #21499 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21499: make install - power_assert is a runtime_dependency of test-unit https://bugs.ruby-lang.org/issues/21499 * Author: MSP-Greg (Greg L) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The below is shown in the `make install` log of master. But, `test-unit` has `power_assert` as a runtime_dependency. ``` Extracting bundle gem power_assert-2.0.5... Try with hash version of bundled gems instead of gems/power_assert-2.0.5.gem. We don't use this gem with release version of Ruby. Unpacked gems/power_assert-3.0.0dev.gem ``` So, `test-unit` cannot be required or have its CLI binstub checked... -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122647] [Ruby Bug#17359] Ractor copy mode is not Ractor-safe
by jhawthorn (John Hawthorn) 03 Jul '25

03 Jul '25

Issue #17359 has been updated by jhawthorn (John Hawthorn). Seems to still be an issue. Here's an updated reproduction for 3.5dev (Using Ractor::Port instead of take/yield) ``` ruby class Foo attr_accessor :x def initialize_copy(*) $last = self super end end o = Foo.new o.x = 42 port = Ractor::Port.new r = Ractor.new(o, port) do |copy, port| puts copy.x # => 42 port << :sync Ractor.receive puts copy.x # => 666 end port.receive # => :sync $last.x = 666 r.send :continue r.join ``` ---------------------------------------- Bug #17359: Ractor copy mode is not Ractor-safe https://bugs.ruby-lang.org/issues/17359#change-113923 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Assignee: ractor * ruby -v: ruby 3.0.0dev (2020-11-30T10:06:25Z master 89774a938a) [x86_64-darwin18] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- It should not be possible to mutate an object across Ractors, but the copy mode allows it currently: ```ruby class Foo attr_accessor :x def initialize_copy(*) $last = self super end end o = Foo.new o.x = 42 r = Ractor.new(o) do |copy| puts copy.x # => 42 Ractor.yield :sync Ractor.yield :sync puts copy.x # => 666 end r.take # => :sync $last.x = 666 r.take # => :sync r.take ``` Maybe the `copy` object should be marked as moved? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122646] [Ruby Bug#18733] Heavy GC allocations cause performance issue with Ractor
by jhawthorn (John Hawthorn) 03 Jul '25

03 Jul '25

Issue #18733 has been updated by jhawthorn (John Hawthorn). Subject changed from Ruby GC problems cause performance issue with Ractor to Heavy GC allocations cause performance issue with Ractor This performance gap no longer exists on master. Benchmark from my Ryzen 7 3700X running linux: ``` ❯ ruby -v ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] ❯ RUBY_MAX_CPU=16 ruby test.rb 0.000000 0.003827 19.434401 ( 2.459187) test.rb:20: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. 176.949877 0.005083 176.954960 ( 22.663767) ``` ``` ❯ ruby -v ruby 3.5.0dev (2025-07-02T20:01:24Z master d5f5a56bf2) +PRISM [x86_64-linux] ❯ RUBY_MAX_CPU=16 ruby test.rb 0.000477 0.003464 20.087896 ( 2.532730) test.rb:20: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. 20.272416 0.001401 20.273817 ( 2.576483) ``` I get similar results on my M4 macbook pro A part of this is because `[0,1].include?(x)` no longer allocates (https://github.com/ruby/ruby/commit/1dd40ec18a55ff46f52d0ba44ff5d7923f57c08f) but that was also the case in Ruby 3.4. Modifying the benchmark to use `[0,1].itself.include?(x)` to avoid eliding the Array we can still reproduce the original issue, though it's clear we are making progress. ``` ruby require 'benchmark' def fib(n) return n if [0,1].itself.include?(n) fib(n-1) + fib(n-2) end tp = [] puts Benchmark.measure { 8.times do tp << fork { fib(37) } end tp.each { |t| Process.wait(t) } } puts Benchmark.measure { 8.times.map { Ractor.new { fib(37) } }.each(&:join) } ``` ``` ❯ RUBY_MAX_CPU=16 ruby test.rb 0.000048 0.004020 53.875052 ( 6.815713) test.rb:20: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. 123.640647 27.657227 151.297874 ( 42.308539) ``` I've uploaded a profile here https://share.firefox.dev/44w9adY. We can see that the additional time is spent in GC (sweeping or joining the barrier from a GC step another Ractor initiated) ---------------------------------------- Bug #18733: Heavy GC allocations cause performance issue with Ractor https://bugs.ruby-lang.org/issues/18733#change-113922 * Author: jakit (Jakit Liang) * Status: Assigned * Assignee: ractor * ruby -v: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Code: ``` require 'benchmark' def fib(n) return n if [0,1].include?(n) fib(n-1) + fib(n-2) end tp = [] puts Benchmark.measure { 8.times do tp << fork { fib(37) } end tp.each { |t| Process.wait(t) } } puts Benchmark.measure { 8.times.map { Ractor.new { fib(37) } }.each{ |r| r.take } } ``` Result: |A |B | |--|--| | fork | 0.000264 0.003439 87.181198 ( 11.211349) | | Ractor | 80.292916 15.062559 95.355475 ( 39.569527) | And I found that here's the problem showing on the ActiveMonitor.app: ![ruby_bug_with_m1](http://jakit.cn/screen_shot_ruby_bug.jpg) As you can see, the process of ruby is always using all Performance Cores on my Apple M1 Mac. But there's no one of the Efficiency Cores was in used by ruby Ractor. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115203] [Ruby master Bug#19981] bootstraptest/test_ractor.rb: Segmentation fault on arm32
by jaruga (Jun Aruga) 02 Jul '25

02 Jul '25

Issue #19981 has been reported by jaruga (Jun Aruga). ---------------------------------------- Bug #19981: bootstraptest/test_ractor.rb: Segmentation fault on arm32 https://bugs.ruby-lang.org/issues/19981 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I faced the following segmentation fault on Ubuntu jammy arm32 (emulated environment by `SETARCH='setarch linux32 --verbose --32bit'`) in both Travis CI arm64 [log](https://app.travis-ci.com/github/ruby/ruby/jobs/612418476#L2422 ) and RubyCI arm64-neoverse server. I tested it on the latest ruby master branch `14fa5e39d72c84d3e12e10dc5d77a6e6200c10f5`. I was able to reproduce this issue on RubyCI arm64-neoverse server, and prepared the reproducing script. So, you can try to debug on the server. It seems that the `-O3` flag triggered the issue. Because I didn't see the issue when Travis CI setting `- optflags=-O1` in `.travis.yml` on the current master branch. https://github.com/junaruga/report-ruby-ractor-segmentation-fault ``` + arm-linux-gnueabihf-gcc --version arm-linux-gnueabihf-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 + setarch linux32 --verbose --32bit make -s test Switching on ADDR_LIMIT_32BIT. Execute command `make'. Fstderr output is not empty <internal:ractor>:760: [BUG] Segmentation fault at 0x0000000c ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [armv8l-linux-eabihf] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0021 e:000020 METHOD <internal:ractor>:760 c:0004 p:0008 s:0014 e:000013 BLOCK bootstraptest.test_ractor.rb_541_1260.rb:4 c:0003 p:0018 s:0011 e:000010 METHOD <internal:kernel>:187 c:0002 p:0004 s:0006 e:000005 BLOCK bootstraptest.test_ractor.rb_541_1260.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bootstraptest.test_ractor.rb_541_1260.rb:3:in `block in <main>' <internal:kernel>:187:in `loop' bootstraptest.test_ractor.rb_541_1260.rb:4:in `block (2 levels) in <main>' <internal:ractor>:760:in `yield' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ r0: 0x00000000 r1: 0x00000001 r2: 0x00000007 r3: 0x00000000 r4: 0x00c935c8 r5: 0x00000002 r6: 0x00000002 r7: 0x00000000 r8: 0x00000004 r9: 0x00c646b0 r10: 0x00000002 sp: 0xd5d91c90 fau: 0x0000000c -- Other runtime information ----------------------------------------------- * Loaded script: bootstraptest.test_ractor.rb_541_1260.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so 7 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so * Process memory map: 00640000-0093a000 r-xp 00000000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094a000-0094e000 r--p 002fa000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094e000-0094f000 rw-p 002fe000 103:03 29263803 /home/jaruga/git/ruby/ruby/build/ruby 0094f000-00956000 rw-p 00000000 00:00 0 00bf3000-00cba000 rw-p 00000000 00:00 0 [heap] d5700000-d5721000 rw-p 00000000 00:00 0 d5721000-d5800000 ---p 00000000 00:00 0 d5900000-d5921000 rw-p 00000000 00:00 0 d5921000-d5a00000 ---p 00000000 00:00 0 d5a00000-d5a21000 rw-p 00000000 00:00 0 d5a21000-d5b00000 ---p 00000000 00:00 0 d5b00000-d5b21000 rw-p 00000000 00:00 0 d5b21000-d5c00000 ---p 00000000 00:00 0 d5c5f000-d5c60000 ---p 00000000 00:00 0 d5c60000-d5c90000 rw-p 00000000 00:00 0 d5c9f000-d5ca0000 ---p 00000000 00:00 0 d5ca0000-d5cd0000 rw-p 00000000 00:00 0 d5cde000-d5cdf000 ---p 00000000 00:00 0 d5cdf000-d5cef000 rw-p 00000000 00:00 0 d5cef000-d5cf0000 ---p 00000000 00:00 0 d5cf0000-d5d81000 rw-p 00000000 00:00 0 d5d81000-d5d82000 ---p 00000000 00:00 0 d5d82000-d5e12000 rw-p 00000000 00:00 0 d5e12000-d5e13000 ---p 00000000 00:00 0 d5e13000-d5ea3000 rw-p 00000000 00:00 0 d5ea3000-d5ea4000 ---p 00000000 00:00 0 d5ea4000-d5f34000 rw-p 00000000 00:00 0 d5f34000-d5f35000 ---p 00000000 00:00 0 d5f35000-d5fc5000 rw-p 00000000 00:00 0 d5fc5000-d5fc6000 ---p 00000000 00:00 0 d5fc6000-d6056000 rw-p 00000000 00:00 0 d6056000-d6057000 ---p 00000000 00:00 0 d6057000-d60e7000 rw-p 00000000 00:00 0 d60e7000-d60e8000 ---p 00000000 00:00 0 d60e8000-d6178000 rw-p 00000000 00:00 0 d6178000-d6179000 ---p 00000000 00:00 0 d6179000-d6209000 rw-p 00000000 00:00 0 d6209000-d620a000 ---p 00000000 00:00 0 d620a000-d629a000 rw-p 00000000 00:00 0 d629a000-d629b000 ---p 00000000 00:00 0 d629b000-d632b000 rw-p 00000000 00:00 0 d632b000-d632c000 ---p 00000000 00:00 0 d632c000-f5d10000 rw-p 00000000 00:00 0 f5d10000-f5d12000 r-xp 00000000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d12000-f5d21000 ---p 00002000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d21000-f5d22000 r--p 00001000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d22000-f5d23000 rw-p 00002000 103:03 29263555 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/trans/transdb.so f5d30000-f5d32000 r-xp 00000000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d32000-f5d41000 ---p 00002000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d41000-f5d42000 r--p 00001000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d42000-f5d43000 rw-p 00002000 103:03 29263548 /home/jaruga/git/ruby/ruby/build/.ext/armv8l-linux-eabihf/enc/encdb.so f5d4f000-f5d50000 ---p 00000000 00:00 0 f5d50000-f5d71000 rw-p 00000000 00:00 0 f5d71000-f5d72000 ---p 00000000 00:00 0 f5d72000-f5d93000 rw-p 00000000 00:00 0 f5d93000-f5d94000 ---p 00000000 00:00 0 f5d94000-f5db5000 rw-p 00000000 00:00 0 f5db5000-f5db6000 ---p 00000000 00:00 0 f5db6000-f5dd7000 rw-p 00000000 00:00 0 f5dd7000-f5dd8000 ---p 00000000 00:00 0 f5dd8000-f5df9000 rw-p 00000000 00:00 0 f5df9000-f5dfa000 ---p 00000000 00:00 0 f5dfa000-f5e1b000 rw-p 00000000 00:00 0 f5e1b000-f5e1c000 ---p 00000000 00:00 0 f5e1c000-f5e3d000 rw-p 00000000 00:00 0 f5e3d000-f5e3e000 ---p 00000000 00:00 0 f5e3e000-f5e5f000 rw-p 00000000 00:00 0 f5e5f000-f5e60000 ---p 00000000 00:00 0 f5e60000-f66a0000 rw-p 00000000 00:00 0 f66af000-f73b0000 rw-p 00000000 00:00 0 f73b5000-f7436000 rw-p 00000000 00:00 0 f7436000-f76b0000 r--p 0006f000 103:03 11802136 /usr/lib/locale/locale-archive f76b0000-f78b0000 r--p 00000000 103:03 11802136 /usr/lib/locale/locale-archive f78b0000-f79bc000 r-xp 00000000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79bc000-f79cc000 ---p 0010c000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79cc000-f79ce000 r--p 0010c000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79ce000-f79cf000 rw-p 0010e000 103:03 11670018 /usr/lib/arm-linux-gnueabihf/libc.so.6 f79cf000-f79d9000 rw-p 00000000 00:00 0 f79e0000-f7a21000 r-xp 00000000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a21000-f7a30000 ---p 00041000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a30000-f7a31000 r--p 00040000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a31000-f7a32000 rw-p 00041000 103:03 11670021 /usr/lib/arm-linux-gnueabihf/libm.so.6 f7a40000-f7a6b000 r-xp 00000000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a6b000-f7a7b000 ---p 0002b000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7b000-f7a7c000 r--p 0002b000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7c000-f7a7d000 rw-p 0002c000 103:03 11670013 /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0 f7a7d000-f7a85000 rw-p 00000000 00:00 0 f7a88000-f7aa7000 r-xp 00000000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 f7aac000-f7ab3000 r--s 00000000 103:03 11670285 /usr/lib/arm-linux-gnueabihf/gconv/gconv-modules.cache f7ab3000-f7ab5000 rw-p 00000000 00:00 0 f7ab5000-f7ab6000 r-xp 00000000 00:00 0 [sigpage] f7ab6000-f7ab8000 r--p 0001e000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 f7ab8000-f7ab9000 rw-p 00020000 103:03 11670015 /usr/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ff7dd000-fffdc000 rw-p 00000000 00:00 0 [stack] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120601] [Ruby master Bug#21024] Ruby including <cstdbool> generates compilation warning with GCC 15, header is deprecated in C++17,
by jprokop (Jarek Prokop) 02 Jul '25

02 Jul '25

Issue #21024 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #21024: Ruby including <cstdbool> generates compilation warning with GCC 15, header is deprecated in C++17, https://bugs.ruby-lang.org/issues/21024 * Author: jprokop (Jarek Prokop) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- C++ compiler in GCC 15 now generates a warning when trying to include `<cstdbool>`. This file is being included when compiling with C++ compiler from `include/ruby/internal/stdbool.h`. In C++, true, false and bool are keywords so including headers for boolean definitions should not be necessary. Alternatively, just including <stdbool.h> should be sufficient as that is what the `#include <cstdbool>` results in with GCC. Simplest fix is just deleting the lines that are including the file (see attached patch and comments 2 and 3 from downstream issue linked in the bottom section "Additional info"). Considering the wide array of compilers Ruby aims to support to be compiled with I wanted to make an issue here first to make sure there isn't a supported compiler that wouldn't agree with this approach. Reproduction: Obtain GCC 15, for Fedora Rawhide there is currently a repo of maintainer, I use it in Fedora Rawhide container (podman is replaceable for docker here): ``` host$ podman run -it --rm registry.fedoraproject.org/fedora:rawhide bash container# echo "[gcc_15] name=pre-release GCC 15 Repo baseurl=https://fedorapeople.org/~dmalcolm/gcc/gcc-15-mass-prebuild/$basear… type=rpm-md skip_if_unavailable=True gpgcheck=0 repo_gpgcheck=0 enabled=1 enabled_metadata=1" > /etc/yum.repos.d/gcc_15.repo container# dnf install --assumeyes g++ ruby-devel ``` ^ should install `g++-15.0.0` and `ruby.h` needed for the reproducer. Note: that baseurl is a custom space of a Fedora maintainer. Have a file named for example `main.cpp`: ``` cpp #include <ruby.h> int main(void) { return 0; } ``` Compile with GCC 15 ``` $ g++ main.cpp ``` Current behavior: Compiling throws warning: ``` $ g++ main.cpp In file included from /usr/include/ruby/internal/stdbool.h:30, from /usr/include/ruby/backward/2/bool.h:22, from /usr/include/ruby/defines.h:74, from /usr/include/ruby/ruby.h:25, from /usr/include/ruby.h:38, from reproducer.cpp:1: /usr/include/c++/15/cstdbool:48:6: warning: #warning "<cstdbool> is deprecated in C++17, remove the #include" [-Wcpp] 48 | # warning "<cstdbool> is deprecated in C++17, remove the #include" | ^~~~~~~ ``` Expected: Compilation throws no warnings and compiles the executable: ``` $ g++ reproducer.cpp $ echo $? 0 ``` Additional info: ``` $ g++ --version g++ (GCC) 15.0.0 20241203 (Red Hat 15.0.0-0) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` This was met during recompilation of libdnf5 that includes `-Werror` in their compilation flags, See downstream discussion: https://bugzilla.redhat.com/show_bug.cgi?id=2336567 Considering the inclusion of the <cstdbool> throws me up to 5 years ago back ( https://github.com/ruby/ruby/blob/9e6e39c3512f7a962c44dc3729c98a0f8be90341/… ), I assume this warning will be the case with older rubies as well as newest master when using GCC 15. ---Files-------------------------------- 0001-Stop-including-cstdbool-in-include-ruby-internal-std.patch (869 Bytes) -- https://bugs.ruby-lang.org/

5 6

[ruby-core:122636] [Ruby Bug#21495] IO.read_nonblock does not work under a rescue IO::TimeoutError
by dE (dE Techno) 01 Jul '25

01 Jul '25

Issue #21495 has been reported by dE (dE Techno). ---------------------------------------- Bug #21495: IO.read_nonblock does not work under a rescue IO::TimeoutError https://bugs.ruby-lang.org/issues/21495 * Author: dE (dE Techno) * Status: Open * ruby -v: de@myworkstation ~/docs/Practice/Software/ruby $ ruby -v ruby 3.2.8 (2025-03-26 revision 13f495dc2c) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In this particular code -- ``` ruby execArg = 'echo testwrite; sleep 5' tofuProcess = IO.popen(execArg, 'r') puts 'executed tofu process.' tofuProcess.timeout=2 begin tofuOut = tofuProcess.read rescue IO::TimeoutError puts 'rescue occured' begin tofuOut = tofuProcess.read_nonblock(1) rescue IO::EAGAINWaitReadable puts 'no data in read buffer!' end tofuProcess.close puts 'process closed' end ``` tofuProcess.read_nonblock(1) must return a character because the underlying process has produced an output. But it raises a IO::EAGAINWaitReadable exception instead which does not happen outside a rescue IO::TimeoutError block -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122625] [Ruby Bug#21461] Heap-buffer-overflow in Prism when encoding magic comment is invalid and assignment is incomplete
by bendrissou (Bachir Bendrissou) 01 Jul '25

01 Jul '25

Issue #21461 has been reported by bendrissou (Bachir Bendrissou). ---------------------------------------- Bug #21461: Heap-buffer-overflow in Prism when encoding magic comment is invalid and assignment is incomplete https://bugs.ruby-lang.org/issues/21461 * Author: bendrissou (Bachir Bendrissou) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ### Description An AddressSanitizer (ASan) heap-buffer-overflow occurs in Ruby when: 1. The file contains an invalid magic encoding comment, and 2. A line with incomplete assignment (e.g. missing right-hand side). This leads to a crash in pm_parse_errors_format_sort, caused by prism_compile.c accessing a freed or uninitialized memory region. ### Input ``` # -*- coding: abc -*- $a = ``` ### Expected output ``` unknown or invalid encoding in the magic comment (ArgumentError) ``` ### ASAN output ``` ================================================================= ==719525==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300002af88 at pc 0x559137d4f16a bp 0x7ffd85551fe0 sp 0x7ffd85551fd0 WRITE of size 8 at 0x60300002af88 thread T0 #0 0x559137d4f169 in pm_parse_errors_format_sort ../prism_compile.c:10620 #1 0x559137d4f169 in pm_parse_errors_format ../prism_compile.c:10687 #2 0x559137e08753 in pm_parse_process_error ../prism_compile.c:10999 #3 0x559137e08753 in pm_parse_process ../prism_compile.c:11105 #4 0x559137e7811d in pm_parse_file ../prism_compile.c:11391 #5 0x559137960743 in prism_script ../ruby.c:2236 #6 0x559137960743 in process_options ../ruby.c:2563 #7 0x55913796228f in ruby_process_options ../ruby.c:3199 #8 0x5591376a2406 in ruby_options ../eval.c:117 #9 0x5591376937fe in rb_main ../main.c:42 #10 0x5591376937fe in main ../main.c:62 #11 0x7f69beed2082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) #12 0x559137694dcd in _start (/home/program/build/ruby+0x15cdcd) 0x60300002af88 is located 0 bytes to the right of 24-byte region [0x60300002af70,0x60300002af88) allocated by thread T0 here: #0 0x7f69bf427a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153 #1 0x5591377119bd in calloc1 ../gc/default/default.c:1490 #2 0x5591377119bd in rb_gc_impl_calloc ../gc/default/default.c:8162 #3 0x5591377119bd in ruby_xcalloc_body ../gc.c:5327 SUMMARY: AddressSanitizer: heap-buffer-overflow ../prism_compile.c:10620 in pm_parse_errors_format_sort Shadow bytes around the buggy address: 0x0c067fffd5a0: 00 00 00 00 fa fa 00 00 00 fa fa fa 00 00 00 fa 0x0c067fffd5b0: fa fa fd fd fd fa fa fa 00 00 00 fa fa fa 00 00 0x0c067fffd5c0: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 0x0c067fffd5d0: 00 00 00 00 fa fa 00 00 00 00 fa fa fd fd fd fd 0x0c067fffd5e0: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 =>0x0c067fffd5f0: 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffd600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffd610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffd620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffd630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffd640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==719525==ABORTING input.rb: [BUG] ASAN error ruby 3.5.0dev (2025-06-11T18:07:43Z master 970813d982) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000720 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /lib/x86_64-linux-gnu/libasan.so.5(__interceptor_backtrace+0x40) [0x7f69bf386d40] ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4022 /home/program/build/ruby(rb_print_backtrace+0x11) [0x559137fceda9] ../vm_dump.c:843 /home/program/build/ruby(rb_vm_bugreport) ../vm_dump.c:1175 /home/program/build/ruby(rb_bug_without_die_internal+0xc3) [0x559137efa4b6] ../error.c:1097 /home/program/build/ruby(rb_bug_without_die) ../error.c:1106 /lib/x86_64-linux-gnu/libasan.so.5(0x7f69bf44fe58) [0x7f69bf44fe58] /lib/x86_64-linux-gnu/libasan.so.5(0x7f69bf43152c) [0x7f69bf43152c] /lib/x86_64-linux-gnu/libasan.so.5(0x7f69bf430fa3) [0x7f69bf430fa3] /lib/x86_64-linux-gnu/libasan.so.5(0x7f69bf43238e) [0x7f69bf43238e] /home/program/build/ruby(pm_parse_errors_format_sort+0x12) [0x559137d4f16a] ../prism_compile.c:10620 /home/program/build/ruby(pm_parse_errors_format) ../prism_compile.c:10687 /home/program/build/ruby(pm_parse_process_error+0x84) [0x559137e08754] ../prism_compile.c:10999 /home/program/build/ruby(pm_parse_process) ../prism_compile.c:11105 /home/program/build/ruby(rbimpl_intern_const+0x0) [0x559137e7811e] ../prism_compile.c:11391 /home/program/build/ruby(pm_parse_file) ../prism_compile.c:11396 /home/program/build/ruby(prism_script+0xa4) [0x559137960744] ../ruby.c:2236 /home/program/build/ruby(process_options) ../ruby.c:2563 /home/program/build/ruby(ruby_process_options+0x3f0) [0x559137962290] ../ruby.c:3199 /home/program/build/ruby(ruby_options+0x2a7) [0x5591376a2407] ../eval.c:117 /home/program/build/ruby(rb_main+0x19) [0x5591376937ff] ../main.c:42 /home/program/build/ruby(main) ../main.c:62 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f69beed2083] /home/program/build/ruby(_start) [0x559137694dce] -- Other runtime information ----------------------------------------------- * Loaded script: input.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 set.rb ``` ### Environment Ruby version: ruby 3.5.0dev (2025-06-11 commit 970813d982) +PRISM Platform: x86_64-linux Built from source Parser backend: Prism (default) -- https://bugs.ruby-lang.org/

2 1