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

[ruby-core:115879] [Ruby master Bug#20081] Transfered Fiber doesn't return to Fiber that started it
by rmosolgo (Robert Mosolgo) 01 Jul '26

01 Jul '26

Issue #20081 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #20081: Transfered Fiber doesn't return to Fiber that started it https://bugs.ruby-lang.org/issues/20081 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi! I'm trying to figure out how to make sure that Fibers started with `.transfer` end up _terminated_, not just suspended. (If they're suspended, Rails thinks they're still alive, and they continue to hold onto database connections, see: https://github.com/rmosolgo/graphql-ruby/issues/4739#issuecomment-1866930914.) So, I'm looking for way to make sure that any Fiber I start with `.transfer` will be properly terminated. But what I noticed is that when a transfer-based Fiber terminates, it gives control back to the top-most Fiber, not the Fiber which transfered to it. Is this intended? Here's a script to replicate the issue: ```ruby manager = Fiber.new do parent = Fiber.current worker = Fiber.new do puts "2. Begin Worker" parent.transfer puts "4. End Worker" end puts "1. Transfer 1" worker.transfer puts "3. Transfer 2" worker.transfer puts "5. Finished manager" end manager.transfer puts "6. Finished script" ``` I expect the steps to print in order: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 5. Finished manager 6. Finished script ``` But instead, `5. ...` is skipped: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 6. Finished script ``` I think that's because my `worker` fiber terminates and passes control back to the top-level Fiber. Should it have passed control back to the `manager`? Or is there another way to make sure `worker` is terminated, and `manager` gets control? -- https://bugs.ruby-lang.org/

3 9

[ruby-core:116949] [Ruby master Misc#20303] Troubleshooting Guide for Common Issues with GMC Acadia
by adamrojas (Adam Rojas) 23 Jun '26

23 Jun '26

Issue #20303 has been reported by adamrojas (Adam Rojas). ---------------------------------------- Misc #20303: Troubleshooting Guide for Common Issues with GMC Acadia https://bugs.ruby-lang.org/issues/20303 * Author: adamrojas (Adam Rojas) * Status: Open ---------------------------------------- Owning a GMC Acadia brings numerous benefits, yet like any vehicle, it may encounter issues. In this guide, we’ll delve into common problems reported by GMC Acadia owners and offer effective solutions. ![Troubleshooting Guide for Common Issues with GMC Acadia](https://autorepairandservice.files.wordpress.com/2024/02/troublesho… Whether you’re dealing with transmission faults, engine light codes, or other issues, we’ve got you covered. ## **Troubles with Transmission and Check Engine Light:** ![Troubles with Transmission and Check Engine Light](https://autorepairandservice.files.wordpress.com/2024/02/troubles-wi… One significant challenge faced by GMC Acadia owners revolves around transmission faults, often accompanied by the illumination of the check engine light. This issue, reported by numerous individuals, demands prompt attention to prevent further complications. Seeking assistance from experienced professionals is recommended to diagnose and address these transmission-related concerns effectively, ensuring the continued reliability and performance of your vehicle. ## **Interpreting Check Engine Light Codes:** ![Interpreting Check Engine Light Codes](https://autorepairandservice.files.wordpress.com/2024/02/interpretin… Another common issue encountered by GMC Acadia owners involves the activation of the check engine light, often accompanied by specific diagnostic trouble codes (DTCs). Understanding these codes is essential for identifying underlying issues promptly. Seeking assistance from a qualified mechanic for thorough diagnostics and appropriate remedies is advised to prevent potential engine damage and ensure continued vehicle reliability. ## **Addressing Gas Cap Concerns and Check Engine Light Illumination:** ![Addressing Gas Cap Concerns and Check Engine Light Illumination](https://autorepairandservice.files.wordpress.com/2024/02/addr… Another area of concern for GMC Acadia owners involves issues related to the gas cap, which can lead to the illumination of the check engine light. This problem, while less common, should not be overlooked. It’s important to ensure the gas cap is securely tightened to prevent evaporation and maintain proper fuel system pressure. If the check engine light persists after verifying the gas cap’s tightness, seeking assistance from a qualified technician is advisable to diagnose and resolve any underlying issues effectively. ## **Navigating GMC Acadia Electrical Issues:** ![Navigating GMC Acadia Electrical Issues](https://autorepairandservice.files.wordpress.com/2024/02/navigating… Electrical problems can pose significant challenges for GMC Acadia owners, affecting various systems within the vehicle. These issues might manifest as malfunctioning lights, power window failures, intermittent electrical failures, or battery drainage concerns. Addressing electrical problems promptly is crucial to prevent further complications and ensure the safety and functionality of your Acadia. Seeking assistance from experienced technicians equipped with diagnostic tools and expertise in automotive electrical systems is essential for accurately identifying and resolving these issues, restoring your vehicle’s performance and reliability. ## **Essential Maintenance Tasks for GMC Acadia Owners:** ![Essential Maintenance Tasks for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/essential-… Beyond adhering to scheduled maintenance, there are fundamental tasks that every GMC Acadia owner should prioritize. These include: **1. Regular Brake Fluid Flushes:** To uphold braking effectiveness, it’s crucial to schedule regular brake fluid flushes. This process helps prevent contaminants from compromising the brake system’s performance, ensuring optimal safety on the road. **2. Transmission Inspections:** Regular inspections of the transmission are essential for early detection of potential issues. By identifying any signs of wear or malfunction early on, owners can mitigate the risk of costly repairs and ensure smooth operation of their Acadia. **3. Coolant Inspections:** Preventing overheating is vital for maintaining engine health. Regular coolant inspections help owners monitor coolant levels and quality, ensuring proper engine temperature regulation and preventing potential damage due to overheating. **4. Spark Plug Replacements:** Spark plugs play a critical role in engine performance by igniting the air-fuel mixture in the cylinders. Replacing worn-out spark plugs at recommended intervals helps maintain fuel efficiency, prevent misfires, and ensure optimal engine performance. ## **Expert Tips for GMC Acadia Owners:** ![Expert Tips for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/expert-tip… Routine inspections and preventive measures are key to maintaining your GMC Acadia’s performance and longevity. Beyond addressing specific issues and adhering to maintenance schedules, here are some expert tips to keep your vehicle running smoothly: **1. Driving Habits Matter:** Be mindful of your driving habits to minimize wear and tear on your Acadia. Avoid sudden acceleration or braking whenever possible, and practice smooth, gradual maneuvers to reduce strain on the engine, transmission, and other vital components. **2. Stay Informed and Educated:** Stay updated on recalls, service bulletins, and manufacturer recommendations for your GMC Acadia. Joining online forums or communities dedicated to GMC owners can provide valuable insights and tips from fellow enthusiasts and experts. Keeping yourself informed empowers you to make informed decisions about your vehicle’s care and maintenance. By incorporating these expert tips into your maintenance routine, you can ensure that your GMC Acadia remains reliable, efficient, and enjoyable to drive for miles to come. ## **Conclusion:** Being aware of common GMC Acadia issues and following proper maintenance practices can ensure trouble-free ownership. Promptly addressing problems through professional diagnosis and repair, along with adhering to recommended maintenance intervals, can help maintain a reliable and enjoyable driving experience. Thank you for reading this post. If you're looking for a car specialist to opt for a [cheap plastic bumper repair in Manchester](https://servicemycar.com/uk/services/car-bumper-repair-manchest…. So, you can connect with Service My Car and get the best car dent service at a very reasonable price. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories
by vo.x (Vit Ondruch) 15 Jun '26

15 Jun '26

Issue #19972 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19972: Install default/bundled gems into dedicated directories https://bugs.ruby-lang.org/issues/19972 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-24 master c44d65427e) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I think that the current situation, where the same directory (lets call it `Gem.default_dir`) is used for default/bundled gems as well as for user installed gems, is suboptimal. During the times, this has caused us quite some issue on Fedora. Historically, we redefined the `Gem.default_dir` to user home directory, to avoid the mixing of system gems and user installed gems. Unfortunately, with advent of default/bundled gems, we were facing issues that these gems were suddenly not listed, etc. I am realizing this issue in full once again since the "user install" RubyGems feature has landed [1]. I also think that we have arrived to this situation by evolution, not by design. Therefore my proposal is: Keep the `Gem.default_dir` for user `gem install`ed gems and lets install default and bundled gems into separate dedicated directories. Have separate `Gem.bundled_gems_dir` and `Gem.default_gems_dir` structures. Of course, if `Gem.default_dir == Gem.bundled_gems_dir == Gem.default_gems_dir`, we still can have the current layout. I have a simple POC here: https://github.com/ruby/ruby/pull/8761 BTW I have reported it here, because I think that RubyGems provides all it is needed. So it is not RubyGems ticket after all. However, I believe that RubyGems could benefit from this long term and some simplifications/cleanups would be possible. [1]: https://github.com/rubygems/rubygems/pull/5327 -- https://bugs.ruby-lang.org/

6 11

[ruby-core:113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument
by shioyama (Chris Salzberg) 10 Jun '26

10 Jun '26

Issue #19633 has been reported by shioyama (Chris Salzberg). ---------------------------------------- Feature #19633: Allow passing block to `Kernel#autoload` as alternative to second `filename` argument https://bugs.ruby-lang.org/issues/19633 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#autoload` takes two arguments, a symbol `module` representing the constant to be autoloaded, and a `filepath` to load the constant from (with `require`). Currently, Zeitwerk has to [monkeypatch `Kernel#require`](https://github.com/fxn/zeitwerk/blob/a7c4a983df0f4e4058f32c610dac1e8b99f687da/lib/zeitwerk/kernel.rb) to fetch the loader for the file being loaded, then run the original (aliased) `require`, then run autoload callbacks. In addition to the monkeypatch, this also requires a registry (`Zeitwerk::Registry`) to map file paths to loaders, to know which loader should be used for a given autoload-triggered `require`. In fact, Zeitwerk has to _assume_ that the monkey-patched `require` call came from an autoload trigger; there is no way to really be sure of the source. If Ruby allowed passing a block as an alternative to the explicit filepath, then I think this could be improved and would eliminate the need for a monkeypatch. So something like this: ```ruby autoload(:B) do require "lib/b" # trigger callback, etc end ``` I am implementing a gem called [Im](https://github.com/shioyama/im) which is a fork of Zeitwerk, and in the case of this gem, such a feature would be even more useful. Im implements autoloads on anonymous modules by registering an autoload and then "catching" the require and converting it into a `load`, passing the module as the second argument (see [here](https://github.com/shioyama/im/blob/44ce348639a1aae563a5be7a40602761e….) This is currently quite tricky because, again, it's hard to know _where_ a `require` came from. In addition to removing the monkeypatch (inherited from Zeitwerk), Im would further benefit from the block argument because then it could simply access the module via a closure, rather than pulling it from a registry: ```ruby mod.autoload(:Foo) do load "lib/foo.rb", mod end ``` I don't know how hard or easy this would be to implement, but if there is interest in this as a feature I'd be happy to look into implementing it. -- https://bugs.ruby-lang.org/

4 16

[ruby-core:111146] [Ruby master Bug#19172] `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change?
by ivoanjo (Ivo Anjo) 15 May '26

15 May '26

Issue #19172 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19172: `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change? https://bugs.ruby-lang.org/issues/19172 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: (All Ruby versions) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the ddtrace gem](https://github.com/DataDog/dd-trace-rb) and I found a... sharp edge on the internal `ruby_thread_has_gvl_p` API. I am aware that `ruby_thread_has_gvl_p` is documented an experimental API that is exported as a symbol but not present on the VM include files. ### Background In the ddtrace profiling component, we setup a signal handler and then periodically send SIGPROF signals to try to interrupt the running Ruby thread (e.g. the thread that is holding the global VM lock or equivalent). In the signal handler, we need to perform some API calls which are not safe to do without the GVL. So we need to check if the signal handler got called in the thread that has the GVL. ### The issue ```ruby int ruby_thread_has_gvl_p(void) { rb_thread_t *th = ruby_thread_from_native(); if (th && th->blocking_region_buffer == 0) { return 1; } else { return 0; } } ``` In its current implementation, `ruby_thread_has_gvl_p` only checks if the thread has a `blocking_region_buffer` or not. Unfortunately, this means that when called from a thread that lost the GVL but not due to blocking (e.g. via `rb_thread_schedule()`), it can still claim that a thread is holding the GVL when that is not the case. I ran into this issue in https://github.com/DataDog/dd-trace-rb/pull/2415, and needed to find a workaround. ### Next steps Since this is an internal VM API, I'm not sure you'd want to change the current behavior, so I was thinking of perhaps two options: * Is it worth changing `ruby_thread_has_gvl_p` to be accurate in the case I've listed? * If not, would you accept a PR to document its current limitations, so that others don't run into the same issue I did? -- https://bugs.ruby-lang.org/

3 3

[ruby-core:117434] [Ruby master Bug#20409] Missing reporting some invalid breaks
by kddnewton (Kevin Newton) 13 May '26

13 May '26

Issue #20409 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20409: Missing reporting some invalid breaks https://bugs.ruby-lang.org/issues/20409 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

4 12

[ruby-core:115241] [Ruby master Bug#19986] Win32: `HOME` is set to just `HOMEDRIVE` if `HOMEPATH` is unset
by nobu (Nobuyoshi Nakada) 10 May '26

10 May '26

Issue #19986 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19986: Win32: `HOME` is set to just `HOMEDRIVE` if `HOMEPATH` is unset https://bugs.ruby-lang.org/issues/19986 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ``` $ env -u HOME -u USERPROFILE -u HOMEPATH HOMEDRIVE=no/such/home ./miniruby.exe -e 'p ENV["HOME"], Dir.home' "no/such/home" "no/such/home" ``` `HOMEDRIVE` should be ignored without `HOMEPATH`, and `HOME` should fallback to `CSIDL_PROFILE`. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118940] [Ruby master Bug#20696] `IO.read` ignores `err:` option
by nobu (Nobuyoshi Nakada) 10 May '26

10 May '26

Issue #20696 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20696: `IO.read` ignores `err:` option https://bugs.ruby-lang.org/issues/20696 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I expected the following code captures the error message, but `err:` option is ignored. ```shell-session $ ruby -e 'p IO.read("|ruby -e raise", err: %i[child out])' -e:1:in '<main>': unhandled exception "" ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 14 Apr '26

14 Apr '26

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/

23 82

[ruby-core:120819] [Ruby master Bug#21097] `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism
by tompng (tomoya ishida) 16 Mar '26

16 Mar '26

Issue #21097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21097: `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism https://bugs.ruby-lang.org/issues/21097 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby x = a rescue b in c (x = (a rescue b)) in c # parse.y, prism(ruby 3.4) x = (a rescue (b in c)) # prism(ruby 3.5) ~~~ ~~~ruby def f = a rescue b in c #=> true(parse.y), :f(prism) (def f = (a rescue b)) in c # parse.y def f = (a rescue (b in c)) # prism ~~~ There is no difference between prism and parse.y parsing these codes ~~~ruby a rescue b in c # a rescue (b in c) x = a rescue b # x = (a rescue b) x = b in c # (x = b) in c def f = a rescue b # def f = (a rescue b) def f = b in c # (def f = a) in b ~~~ -- https://bugs.ruby-lang.org/

9 12