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

[ruby-core:112206] [Ruby master Bug#19407] 2 threads taking from current ractor will hang forever
by luke-gru (Luke Gruber) 21 Aug '25

21 Aug '25

Issue #19407 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19407: 2 threads taking from current ractor will hang forever https://bugs.ruby-lang.org/issues/19407 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the current implementation of Ractors, it's possible to `take` from the current ractor. This could be useful when co-ordinating threads: ```ruby t = Thread.new do obj = Ractor.current.take p obj # do some work with obj end t0 = Thread.new do obj = Ractor.current.take p obj # do some work with obj end Ractor.yield :go ``` However it hangs forever: ```ruby t = Thread.new do obj = Ractor.current.take p obj end t0 = Thread.new do obj = Ractor.current.take p obj end sleep 0.5 ``` Should "self-take" be disabled, or was it designed to allow it but this is just a bug? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115438] [Ruby master Misc#20013] Travis CI status
by jaruga (Jun Aruga) 15 Aug '25

15 Aug '25

Issue #20013 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20013: Travis CI status https://bugs.ruby-lang.org/issues/20013 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- I would like to use this ticket to manage our activities to report Travis CI status. Because there is Travis CI status page provided by Travis CI. However, even when the page shows ok, I actually see infra issues. https://www.traviscistatus.com/ I would share my activities and report the Travis CI status on the ticket. The ticket's status is not closed until we stop using Travis CI. The easiest option to fix the Travis infra issue is to email Travis CI support `support _AT_ travis-ci.com`. You can check [this ruby/ruby Travis CI wiki page](https://github.com/ruby/ruby/wiki/CI-Servers#travis-ci) for details. -- https://bugs.ruby-lang.org/

2 50

[ruby-core:121136] [Ruby master Bug#21151] IO and StringIO raise FrozenError even for read-only methods
by headius (Charles Nutter) 11 Aug '25

11 Aug '25

Issue #21151 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #21151: IO and StringIO raise FrozenError even for read-only methods https://bugs.ruby-lang.org/issues/21151 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Problem -------- While fixing a small [regression](https://github.com/ruby/stringio/issues/119) from my recent StringIO [fixes](https://github.com/ruby/stringio/issues/116) I discovered that a large number of read-only methods will fail if the StringIO is frozen. A few examples: ``` $ ruby -rstringio -e 's = StringIO.new; p s.lineno; s.freeze; p s.lineno' 0 -e:1:in 'StringIO#lineno': can't modify frozen StringIO: #<StringIO:0x0000000103711ea8> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.closed?; s.freeze; p s.closed?' false -e:1:in 'StringIO#closed?': can't modify frozen StringIO: #<StringIO:0x00000001008c1e68> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.eof?; s.freeze; p s.eof?' true -e:1:in 'StringIO#eof?': can't modify frozen StringIO: #<StringIO:0x000000011c171e80> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.pos; s.freeze; p s.pos' 0 -e:1:in 'StringIO#pos': can't modify frozen StringIO: #<StringIO:0x0000000105551df0> (FrozenError) from -e:1:in '<main>' ``` @kou pointed out that IO also raises for at least `lineno` and suggested I re-open the issue here. I still believe these read-only operations should be allowed on frozen IO or StringIO. Cause in StringIO ----------------- This is because the `StringIO` macro calls `get_strio` which calls `rb_io_taint_check` which calls `rb_check_frozen`. The `StringIO` macro is used in almost every method to access the rb_stringio_t data structure. A list of methods I believe should be operable when the StringIO is frozen (in stringio.c definition order): * string (returns underlying String but does not mutate anything) * lineno * pos * closed?/closed_read?/closed_write? * eof/eof? * sync * pid (a dummy method but it writes nothing) * fileno (dummy) * pread (by definition does not modify state) * isatty/tty? * size/length * external_encoding * internal_encoding In addition, `initialize_copy` probably should not require the original StringIO to be writable: ``` $ ruby -rstringio -e 's = StringIO.new("foo"); s.freeze; p s.dup' -e:1:in 'StringIO#initialize_copy': can't modify frozen StringIO: #<StringIO:0x0000000102eb1df8> (FrozenError) from -e:1:in 'Kernel#initialize_dup' from -e:1:in 'Kernel#dup' from -e:1:in '<main>' ``` The data from the original StringIO is unmodified by `initialize_copy`, other than the reference-counting `ptr->count` (which should not be subject to frozen checks). Cause in IO ----------- The `GetOpenFile` macro calls `RB_IO_POINTER` macro which calls `rb_io_taint_check` which calls `rb_check_frozen`. Methods in IO that should work on a frozen IO include any of the above StringIO that currently raise. For example `lineno` uses `GetOpenFile`, but `fileno` does not and does not raise. There's clearly some inconsistency here we can clean up. Origin ------ I believe most of the StringIO cases are caused by this change from 2011 that added frozen checks to StringIO (the class and the macro): https://github.com/ruby/ruby/commit/d8d9bac5c8b071135e50ad3f21c8a9b6a9c06e54 In IO, this behavior dates way back to 2000 by @matz himself: https://github.com/ruby/ruby/commit/087c83d7ceed6893afff93066937fb570ae4a115 Notes ----- I have started to fix the StringIO cases for JRuby in https://github.com/ruby/stringio/pull/122. I could probably fix the C version of StringIO as well, but I'm a little more unsure about how to fix IO. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 10 Aug '25

10 Aug '25

Issue #20205 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as far as I'm aware the plan was initially to make it the default for Ruby 3.0, but this plan was abandoned because it would be too much of a breaking change without any real further notice. According to Matz, he still wishes to enable `frozen_string_literal` by default in the future, but a reasonable migration plan is required. The main issue is backward compatibility, flipping the switch immediately would break a lot of code, so there must be some deprecation period. The usual the path forward for this kind of change is to emit deprecation warnings one of multiple versions in advance. One example of that was the Ruby 2.7 keyword argument deprecation. It was quite verbose, and some users were initially annoyed, but I think the community pulled through it and I don't seem to hear much about it anymore. So for frozen string literals, the first step would be to start warning when a string that would be frozen in the future is mutated. ### Deprecation Warning Implementation I implemented a quick proof of concept with @etienne in https://github.com/Shopify/ruby/pull/549 In short: - Files with `# frozen_string_literal: true` or `# frozen_string_literal: false` don't change in behavior at all. - Files with no `# frozen_string_literal` comment are compiled to use `putchilledstring` opcode instead of regular `putstring`. - This opcode mark the string with a user flag, when these strings are mutated, a warning is issued. Currently the proof of concept issue the warning at the mutation location, which in some case can make locating where the string was allocated a bit hard. But it is possible to improve it so the message also include the location at which the literal string was allocated, and learning from the keyword argument warning experience, we can record which warnings were already issued to avoid spamming users with duplicated warnings. As currently implemented, there is almost no overhead. If we modify the implementation to record the literal location, we'd incur a small memory overhead for each literal string in a file without an explicit `frozen_string_literal` pragma. But I believe we could do it in a way that has no overhead if `Warning[:deprecated] = false`. ### Timeline The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`. I don't have a strong opinion on the pace. - Release `R0`: introduce the deprecation warning (only if deprecation warnings enabled). - Release `R1`: make the deprecation warning show up regardless of verbosity level. - Release `R2`: make string literals frozen by default. ### Impact Given that `rubocop` is quite popular in the community and it has enforced the usage of `# frozen_string_literal: true` for years now, I suspect a large part of the actively maintained codebases in the wild wouldn't see any warnings. And with recent versions of `minitest` enabling deprecation warnings by default (and [potentially RSpec too](https://github.com/rspec/rspec-core/issues/2867)) the few that didn't migrate will likely be made compatible quickly. The real problem of course are the less actively developed libraries and applications. For such cases, any codebase can remain compatible by setting `RUBYOPT="--disable=frozen_string_literal"`, and so even after `R2` release. The flag would never be removed any legacy codebase can continue upgrading Ruby without changing a single line of cod by just flipping this flag. ### Workflow for library maintainers As a library maintainer, fixing the deprecation warnings can be as simple as prepending `# frozen_string_literal: false` at the top of all their source files, and this will keep working forever. Alternatively they can of course make their code compatible with frozen string literals. Code that is frozen string literal compatible doesn't need to explicitly declare it. Only code that need it turned of need to do so. ### Workflow for application owners For application owners, the workflow is the same than for libraries. However if they depend on a gem that hasn't updated, or that they can't upgrade it, they can run their application with `RUBYOPT="--disable=frozen_string_literal"` and it will keep working forever. Any user running into an incompatibility issue can set `RUBYOPT="--disable=frozen_string_literal"` forever, even in `4.x`, the only thing changing is the default value. And any application for which all dependencies have been made fully frozen string literal compatible can set `RUBYOPT="--enable=frozen_string_literal"` and start immediately removing magic comment from their codebase. -- https://bugs.ruby-lang.org/

21 74

[ruby-core:111789] [Ruby master Feature#19333] Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks.
by ioquatix (Samuel Williams) 07 Aug '25

07 Aug '25

Issue #19333 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19333: Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks. https://bugs.ruby-lang.org/issues/19333 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As it stands, Fiber Locals, Thread Locals and Fiber Storage have no way of deleting key-value associations. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 end ``` Because of this, dynamically generated associations can leak over time. This is worse for things like Threads that might be pooled (or maybe an argument against user-space pooling). In any case, having a way to delete those associations would allow application code to at least delete the associations when they no longer make sense. I propose that assigning `nil` to "locals" or "storage" should effectively delete them. e.g. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 Thread.current[name] = nil # delete association end ``` A more invasive alternative would be to define new interfaces like `Thread::Local`, `Fiber::Local` and `Fiber::Storage::Local` (or something) which correctly clean up on GC. -- https://bugs.ruby-lang.org/

3 9

[ruby-core:114590] [Ruby master Bug#19857] Eval coverage is reset after each `eval`.
by ioquatix (Samuel Williams) 06 Aug '25

06 Aug '25

Issue #19857 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19857: Eval coverage is reset after each `eval`. https://bugs.ruby-lang.org/issues/19857 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It seems like `eval` based coverage is reset every time eval is invoked. ```ruby #!/usr/bin/env ruby require 'coverage' def measure(flag) c = Class.new c.class_eval(<<~RUBY, "foo.rb", 1) def foo(flag) if flag puts "foo" else puts "bar" end end RUBY return c.new.foo(flag) end Coverage.start(lines: true, eval: true) # Depending on the order of these two operations, different computation is calculated, because the evaluation of the code is considered different, even if the content/path is the same. measure(false) measure(true) p Coverage.result ``` Further investigation is required. -- https://bugs.ruby-lang.org/

4 20

[ruby-core:121054] [Ruby master Bug#21139] Prism and parse.y parses `it = it` differently
by tompng (tomoya ishida) 05 Aug '25

05 Aug '25

Issue #21139 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21139: Prism and parse.y parses `it = it` differently https://bugs.ruby-lang.org/issues/21139 * Author: tompng (tomoya ishida) * Status: Assigned * Assignee: prism * ruby -v: ruby 3.5.0dev (2025-02-14T16:49:52Z master ee181d1bb7) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ # ruby --parser=parse.y -e "42.tap { it = it; p it }" nil # ruby --parser=prism -e "42.tap { it = it; p it }" 42 ~~~ -- https://bugs.ruby-lang.org/

12 18

[ruby-core:119401] [Ruby master Bug#20776] [PRISM] Pattern matching syntax error message
by nobu (Nobuyoshi Nakada) 29 Jul '25

29 Jul '25

Issue #20776 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20776: [PRISM] Pattern matching syntax error message https://bugs.ruby-lang.org/issues/20776 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Syntax error is fine, but is really expecting end-of-input there? ``` $ ruby -v -e '1 => $g' ruby 3.4.0dev (2024-10-01T14:59:58Z master 169a5ee99e) +PRISM [arm64-darwin23] -e:1: warning: possibly useless use of a variable in void context -e: -e:1: syntax errors found (SyntaxError) > 1 | 1 => $g | ^~ unexpected global variable, expecting end-of-input | ^~ expected a pattern expression after `=>` 2 | ``` And the line 2 is **not** in the input. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120617] [Ruby master Feature#21028] Method for finding why an object isn't Ractor shareable
by tenderlovemaking (Aaron Patterson) 26 Jul '25

26 Jul '25

Issue #21028 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21028: Method for finding why an object isn't Ractor shareable https://bugs.ruby-lang.org/issues/21028 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- `Ractor.shareable?` is easy to use, but if it returns false I would like to be able to figure out what object is causing the data structure to _not_ be Ractor shareable. The context is that I'm trying to make some complex data structures in Rails deeply frozen. If they are deeply frozen they _should_ be Ractor shareable, but `Ractor.shareable?` is returning `false` and it's hard for me to figure out _why_. I would like a method that would either return all unshareable references, or a method that takes a block and unshareable references are yielded to the block. A method like `Ractor.unshareable_references?` or maybe `Ractor.shareable?(obj) { |not_shareable_obj| }` would be very helpful for discovering why an object is not shareable. Thanks! -- https://bugs.ruby-lang.org/

4 6

[ruby-core:121835] [Ruby Bug#21310] YJIT optimization causes incorrect is_a? method evaluation
by ravron-hb (Riley Avron) 24 Jul '25

24 Jul '25

Issue #21310 has been reported by ravron-hb (Riley Avron). ---------------------------------------- Bug #21310: YJIT optimization causes incorrect is_a? method evaluation https://bugs.ruby-lang.org/issues/21310 * Author: ravron-hb (Riley Avron) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Our Rails application contains code like the following: ```ruby result = a_proc.call if result.is_a?(Result) && result.nil? puts('This should be impossible') end ``` With YJIT enabled in dev mode and the `yjit-call-threshold` set to 2, the seemingly impossible condition always evaluates to true, and the `puts` is evaluated. If YJIT is disabled, the code behaves as expected: namely, the condition never evaluates to true. If YJIT is enabled but not in dev mode, with the `yjit-call-threshold` is set to 1,500 (as in our original configuration), the error occurs non-deterministically. We originally discovered this issue while updating to Rails 7.2. The following code began to occasionally fail with a `NoMethodError`, complaining that `nil:NilClass` does not define `success?`: ```ruby result = a_proc.call raise ResultRollbackError, result if result.is_a?(Result) && !result.success? ``` `Result` *does* define `success?`, so it seemed impossible that `result.success?` would be invoked unless `result.is_a?(Result)`, and especially impossible that it would be invoked if `result.nil?`. After various debugging, we added the `if` statement shown in the first code block and discovered that YJIT’s optimizations seem to be incorrect. The inability to predict the possible errors this could cause in our application led us to disable YJIT for our entire application while this behavior persists. Unfortunately, we have not been able to reproduce the error in a self-contained case, which I know will make investigation more difficult. That said, we would like to assist in solving it however possible. We would appreciate guidance on how to obtain relevant debugging information, or suggestions on how we might generate a self-contained reproduction of the issue. We would also be willing to consider allowing a Ruby maintainer to review the actual code demonstrating the issue, though we would probably request that they sign an NDA in that case. -- https://bugs.ruby-lang.org/

4 5