June 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:122502] [Ruby Feature#14915] Deprecate String#crypt
by jhawthorn (John Hawthorn) 10 Jun '25

10 Jun '25

Issue #14915 has been updated by jhawthorn (John Hawthorn). > even if that removal doesn't happen until Ruby 4. 👀 It's been 6 years, is it worth considering `String#crypt`'s removal again? I'd be happy to update Jeremy's patch and gem (which the docs have recommended using since Ruby 2.6). We ran into it today as @luke-gru found a deadlock when it was used with Ractors (PR is open to fix). I also noticed it does not release the GVL despite being possible for it to take a long time to run (minutes!) with certain arguments. I think it would be best for Ruby not to provide such a badly behaved method. ---------------------------------------- Feature #14915: Deprecate String#crypt https://bugs.ruby-lang.org/issues/14915#change-113694 * Author: jeremyevans0 (Jeremy Evans) * Status: Rejected ---------------------------------------- This method is system and implementation dependent, and the portable usage mentioned in the documentation is not truly portable (doesn't work on OpenBSD) and insecure as it uses DES. For systems that lack a crypt(3) implementation, Ruby will happily substitute a version that only supports DES. It's 2018, using DES should be avoided if at all possible. The only internal usage of String#crypt in Ruby is in Webrick, where it uses DES for basic authentication with an htpasswd file. That could and should be changed to use a more secure hash by default (bcrypt since that's the most secure htpasswd format), or at least allow the user to customize Webrick's authentication. I expect there are few if any users actively using Webrick's htpasswd support. This moves the String#crypt implementation to the string/crypt extension, but leaves the String#crypt core method. The core method prints a deprecation warning, then loads the string/crypt extension. The string/crypt extension undefines the String#crypt core method, then defines the previous implementation. Because extensions use extconf.rb instead of configure for their configuration, this ports the related configure.ac code to extconf.rb. I'm not sure that is done correctly and works on all platforms, it will need testing. For systems that lack a crypt(3) implementation, this modifies the fallback code to only define crypt_r, since that is the only function that String#crypt will call in that case. While the patch just deprecates String#crypt, I think we should plan to remove support from ruby: 2.6: core method deprecated 2.7: core method removed, string/crypt extension ships with ruby 2.8: string/crypt extension moves to external gem, not shipped ---Files-------------------------------- 0001-Deprecate-String-crypt-move-implementation-to-string.patch (20.5 KB) 0001-Deprecate-String-crypt.patch (7.48 KB) 0001-Deprecate-String-crypt.patch (7.35 KB) 0001-Deprecate-String-crypt.patch (7.43 KB) deprecate-string-crypt.patch (6.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122501] [Ruby Bug#21402] ruby2_keywords affects methods/procs with post arguments
by jeremyevans0 (Jeremy Evans) 09 Jun '25

09 Jun '25

Issue #21402 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21402: ruby2_keywords affects methods/procs with post arguments https://bugs.ruby-lang.org/issues/21402 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- I believe this is an oversight. We forgot to consider post arguments during the development of `ruby2_keywords`. I believe we should not allow `ruby2_keywords` on methods/procs with post arguments. Example: ```ruby def a(*c, **kw) [c, kw] end def b(*a, b) a(*a, b) end ruby2_keywords(:b) b({foo: 1}, bar: 1) # Currently: [[{foo: 1}], {bar: 1}] # Expected: [[{foo: 1}, {bar: 1}], {}] ``` I think the current behavior is unexpected and undesired, because instead of flagging the last element in the splat array, it flags a post argument. I've submitted a pull request to fix this: https://github.com/ruby/ruby/pull/13475 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122496] [Ruby Bug#21401] ObjectSpace can't count Fibers after using a Ractor
by rmosolgo (Robert Mosolgo) 09 Jun '25

09 Jun '25

Issue #21401 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #21401: ObjectSpace can't count Fibers after using a Ractor https://bugs.ruby-lang.org/issues/21401 * Author: rmosolgo (Robert Mosolgo) * Status: Open * ruby -v: ruby 3.5.0dev (2025-06-09T14:38:29Z master f9966b9b76) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi, thanks for all your great work, Ruby crew! I have a test in my project that uses `ObjectSpace.each_object(Fiber).count` to see how many Fibers have been started by my code. This test started failing when I added other tests using `Ractor`s. I was able to isolate it with this script: ```ruby require "objspace" f = Fiber.new { 1 + 1 } GC.start p ObjectSpace.each_object(Fiber).count # => 2 Ractor.new { 1 + 1 }.take p ObjectSpace.each_object(Fiber).count # => 0 (should be 2) # The fiber _is_ there! p f # #<Fiber:0x0000000100c568a8 ractor_fibers.rb:4 (created)> ``` It seems like `ObjectSpace` can't count fibers for some reason, but I expect it to return the number of Fibers in memory. Other classes like `Hash` and `String` are not affected. It fails on Ruby 3.4.1 and 3.5-dev. I used: - `ruby 3.5.0dev (2025-06-09T14:38:29Z master f9966b9b76) +PRISM [x86_64-darwin22]` - `ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-darwin22]` Please let me know if I can help with anything else in tracking down this bug. Thanks again! -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119683] [Ruby master Feature#20861] Add an environment variable for tuning the default thread quantum
by tenderlovemaking (Aaron Patterson) 08 Jun '25

08 Jun '25

Issue #20861 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #20861: Add an environment variable for tuning the default thread quantum https://bugs.ruby-lang.org/issues/20861 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- The default thread quantum is currently [hard coded at 100ms](https://github.com/ruby/ruby/blob/c7708d22c33040a74ea7ac683bf7407d37…. This can impact multithreaded systems that are trying to process Ruby level CPU bound work at the same time as IO work. I would like to add an environment variable `RUBY_THREAD_DEFAULT_QUANTUM_MS` that allows users to specify the default thread quantum (in milliseconds) via an environment variable. It defaults to our current default of 100ms. I've submitted the patch [here](https://github.com/ruby/ruby/pull/11981). Here is a Ruby program to demonstrate the problem: ```ruby def measure x = Process.clock_gettime(Process::CLOCK_MONOTONIC) yield Process.clock_gettime(Process::CLOCK_MONOTONIC) - x end def fib(n) if n < 2 n else fib(n-2) + fib(n-1) end end # find fib that takes ~500ms fib_i = 50.times.find { |i| measure { fib(i) } >= 0.05 } sleep_i = measure { fib(fib_i) } threads = [ Thread.new { 100.times { sleep(sleep_i) # sometimes stalled waiting for fib's quantum to finish } puts "done 1" }, Thread.new { 100.times { fib(fib_i) }; puts "done 2" }, ] # We expect the total time to be about 100 * sleep_i (~5 seconds) because # theoretically the sleep thread could be done nearly completely in parallel to # the fib thread. # # But because the `sleep` thread is iterating over the sleep call, it must wait # for the `fib` thread to complete its quantum, before it can start the next iteration. # # This means each sleep iteration could take up to `sleep_i + 100ms` # # We're calling that stalled time "waste" total = measure { threads.each(&:join) } waste = total - (sleep_i * 100) p TOTAL: total, WASTE: waste ``` The program has two threads. One thread is using CPU time by computing `fib` in a loop. The other thread is simulating IO time by calling `sleep` in a loop. When the `sleep` call completes, it can stall, waiting for the quantum in the fib thread to expire. That means that each iteration on sleep can actually take `sleep time + thread quantum`, or in this case ~600ms when we expected it to only take ~500ms. Ideally, the above program would take `500ms * 100` since all `sleep` calls should be able to execute in parallel with the `fib` calls. Of course this isn't true because the sleep thread must acquire the GVL before it can continue the next iteration, so there will always be _some_ overhead. This feature is for allowing people to tune that overhead. If we run this program with the default quantum the output looks like this: ``` $ ./miniruby -v fibtest.rb ruby 3.4.0dev (2024-11-01T14:49:50Z quantum-computing c7708d22c3) +PRISM [arm64-darwin24] done 2 done 1 {TOTAL: 12.672821999993175, WASTE: 4.960721996147186} ``` The output shows that our program spent about 5 seconds stalled, waiting to acquire the GVL. With this patch we can lower the default quantum, and the output is like this: ``` $ RUBY_THREAD_DEFAULT_QUANTUM_MS=10 ./miniruby -v fibtest.rb ruby 3.4.0dev (2024-11-01T22:06:35Z quantum-computing 087500643d) +PRISM [arm64-darwin24] done 2 done 1 {TOTAL: 8.898526000091806, WASTE: 1.4168260043952614} ``` Specifying the ENV to change the quantum to 10ms lowered our waste in the program to ~1.4 seconds. It's common for web applications to do mixed CPU and IO bound tasks in threads (see the Puma webserver), so it would be great if there was a way to customize the thread quantum depending on your application's workload. -- https://bugs.ruby-lang.org/

11 23

[ruby-core:115981] [Ruby master Bug#20105] Introduce `IO::Stream` or something similar.
by ioquatix (Samuel Williams) 07 Jun '25

07 Jun '25

Issue #20105 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20105: Introduce `IO::Stream` or something similar. https://bugs.ruby-lang.org/issues/20105 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby's IO class has a general model for streaming IO, including some hidden classes like `IO::generic_readable` and `IO::generic_writable`. As Ruby's core IO classes evolve, gems like `openssl` (see `OpenSSL::Buffering`) need to be updated to support changes to the interface. As it stands, there are changes in `IO` which are not copied to `OpenSSL::Buffering`. I'd like to propose we introduce some shared interface for streams that is used by `IO`, `Socket`, and `OpenSSL` to start with. The general interface would be similar to `IO` and allow code like `OpenSSL` to avoid re-implementing the `IO` interface. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121551] [Ruby Feature#21219] `Object#inspect` accept a list of instance variables to display
by byroot (Jean Boussier) 07 Jun '25

07 Jun '25

Issue #21219 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21219: `Object#inspect` accept a list of instance variables to display https://bugs.ruby-lang.org/issues/21219 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ## Context The default `Object#inspect` implementation is quite useful to have a generic representation of objects in error message and similar places. However sometimes objects are referencing other objects with a very large `inspect` representation, making error message hard to understand. In some other cases, some instance variables are holding secrets such as password or private keys, and the default inspect behavior can cause these secrets to be leaked in logs among other places. You can of course define your own `inspect` implementation for any object, but it's not as simple as it may seems because you need to handle circular references, otherwise you can end up with a `SystemStackError`. Also, it's more minor, but since Ruby 2.7, you can no longer access an object's address, so you can't implement an `inspect` method that is consistent with `Object#inspect` From my experience, user defined implementations of `#inspect` are very rare, and I think the above is in part responsible. ## Feature I think it would be useful if the default `Object#inspect` implementation accepted a list of instance variables to display, so that you could very easily hide internal state, either because it's too verbose, or because it is secret: ```ruby require 'logger' logger = Logger.new(STDOUT) class DatabaseConfig def initialize(host, user, password) @host = host @user = user @password = password end def inspect = super(instance_variables: [:@host, :@user]) end env = {db_config: DatabaseConfig.new("localhost", "root", "hunter2")} logger.info("something happened, env: #{env}") ``` ``` INFO -- : something happened, env: {db_config: #<DatabaseConfig:0x00000001002b3a08 @host="localhost", @user="root">} ``` -- https://bugs.ruby-lang.org/

6 9

[ruby-core:122489] [Ruby Bug#17617] When a Ractor's incoming port is closed, Ractor.receive_if does not raise Ractor::ClosedError, but instead blocks indefinitely
by jhawthorn (John Hawthorn) 06 Jun '25

06 Jun '25

Issue #17617 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed `receive_if` has been removed with the introduction of `Ractor::Port`, so this should no longer be an issue ---------------------------------------- Bug #17617: When a Ractor's incoming port is closed, Ractor.receive_if does not raise Ractor::ClosedError, but instead blocks indefinitely https://bugs.ruby-lang.org/issues/17617#change-113678 * Author: dazuma (Daniel Azuma) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.3.0dev (2023-11-13T21:00:10Z master e8ab3f7010) [x86_64-darwin23] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- If Ractor#close_incoming is called on a Ractor, any pending Ractor.receive call will raise Ractor::ClosedError. However, any pending Ractor.receive_if call will not; instead, it never returns. ``` r1 = Ractor.new do Ractor.receive rescue => e e end r1.close_incoming result = r1.take puts "**** taken: #{result}" # displays the Ractor::ClosedError r2 = Ractor.new do Ractor.receive_if { true } puts "**** never reaches here" rescue => e puts "**** never reaches here" e end r2.close_incoming puts "**** hangs here..." r2.take puts "**** never reaches here" ``` This was tested against both 3.0.0 and 3.1.0 head, with the same result. ``` % ruby -v ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20] ``` ``` % ruby -v ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20 ``` I have also tried including sleep statements to force the Ractor.receive_if to execute both before and after the Ractor#close_incoming call. The result is the same either way. receive_if hangs regardless of whether the incoming port is already closed when receive_if is invoked, or whether the port is closed while the receive_if is already blocking. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121182] [Ruby master Bug#21158] Ractor using 'receive_if' sits in busy wait when there are skipped messages in the incoming queue
by NeilW (Neil Wilson) 06 Jun '25

06 Jun '25

Issue #21158 has been reported by NeilW (Neil Wilson). ---------------------------------------- Bug #21158: Ractor using 'receive_if' sits in busy wait when there are skipped messages in the incoming queue https://bugs.ruby-lang.org/issues/21158 * Author: NeilW (Neil Wilson) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When using the conditional receive example from the Ractor documentation (either as a script, or within irb) <pre> r = Ractor.new do val = Ractor.receive_if{|msg| msg.is_a?(Array)} puts "Received successfully: #{val}" end r.send(1) r.send('test') </pre> ruby will sit in busy wait, pegging the processor at 100%, until it gets a message that matches the condition. Within irb it will often stop the REPL responding. The same problem occurs on ruby 3.02, 3.3.7 and 3.4.1 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122265] [Ruby Misc#21369] Propose Max Bernstein (@tekknolagi) as a core committer
by k0kubun (Takashi Kokubun) 06 Jun '25

06 Jun '25

Issue #21369 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21369: Propose Max Bernstein (@tekknolagi) as a core committer https://bugs.ruby-lang.org/issues/21369 * Author: k0kubun (Takashi Kokubun) * Status: Open ---------------------------------------- ## Proposal I'd like to propose Max Bernstein (@tekknolagi) as a committer. He has a strong background in compilers, having previously worked on CPython/Cinder at Meta, and has demonstrated leadership in designing and optimizing ZJIT. Given that he is leading the development of the ZJIT IR and has been making a lot of contributions, I believe he should be empowered to merge such changes himself. I'll include his message below for reference: ## Max Bernstein's Message I have been working on Ruby since December 2024. My main contributions so far have been to ZJIT: * The high-level IR (HIR) data structures * The IR * The type lattice https://github.com/Shopify/zjit/pull/19 * Transforming YARV bytecode into HIR * Optimization on HIR, such as * Type inference https://github.com/Shopify/zjit/pull/23 * Constant folding https://github.com/Shopify/zjit/pull/74 * Direct calls https://github.com/Shopify/zjit/pull/84 * Strength reduction * Dead code elimination (DCE) https://github.com/Shopify/zjit/pull/89 After we moved the ZJIT repo into ruby/ruby, I have continued contributing (see [all PRs](https://github.com/ruby/ruby/pulls?q=author%3Atekknolagi)) I would like to continue contributing to ZJIT and eventually to other parts of Ruby too. Being a maintainer would make it easier to work on ZJIT, especially as we continue the project bringup phase. -- https://bugs.ruby-lang.org/

7 7

[ruby-core:121443] [Ruby Bug#21198] Fiber::Scheduler#blocking_operation_wait crash due to stack-use-after-return
by peterzhu2118 (Peter Zhu) 06 Jun '25

06 Jun '25

Issue #21198 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21198: Fiber::Scheduler#blocking_operation_wait crash due to stack-use-after-return https://bugs.ruby-lang.org/issues/21198 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- The Fiber::Scheduler#blocking_operation_wait method is passed a proc through the `rb_fiber_scheduler_blocking_operation_wait` function. This function stack allocates the arguments used for the proc ([source](https://github.com/ruby/ruby/blob/2183899fd184ab1cfee80d57c0dd6f4dc…) If this proc is captured anywhere, then calling it again will illegally read from and write to stack space. The following script demonstrates this issue using the [test/fiber/scheduler.rb](https://github.com/ruby/ruby/blob/master/test/fibe… scheduler: ```ruby require_relative "test/fiber/scheduler" class MyScheduler < Scheduler def blocking_operation_wait(work) super $work = work end end scheduler = MyScheduler.new Fiber.set_scheduler(scheduler) require "tempfile" Fiber.schedule do file = Tempfile.new file.write("hello world!") $work.call end scheduler.run ``` Crashes with: ``` test.rb:19: [BUG] Bus Error at 0xce0f57696add0045 ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 IFUNC c:0002 p:0017 s:0007 e:000006 BLOCK test.rb:19 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:19:in 'block in <main>' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 Note that the Fiber scheduler is enabled -- Machine register context ------------------------------------------------ x0: 0x000000010063a5f0 x1: 0x000000014b80ce00 x2: 0x0000000000000000 x3: 0x000000014b60f060 x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000004 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000014b6a4840 x20: 0xce0f57696add0045 x21: 0x000000010063a5f0 x22: 0x000000014b60f060 x23: 0x0000000000000000 x24: 0x000000014b60f998 x25: 0x0000000000014273 x26: 0x000000014b60f060 x27: 0x000000014b60f060 x28: 0x000000014b80ce00 lr: 0x0000000100d881d8 fp: 0x000000011bb039f0 sp: 0x000000011bb03980 -- C level backtrace information ------------------------------------------- SEGV received in BUS handler [1] 52599 abort ruby test.rb ``` -- https://bugs.ruby-lang.org/

2 3