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

[ruby-core:126706] [Ruby Bug#11438] native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32
by k0kubun (Takashi Kokubun) 14 Sep '26

14 Sep '26

Issue #11438 has been updated by k0kubun (Takashi Kokubun). Backport changed from 3.3: WONTFIX, 3.4: DONE, 4.0: REQUIRED to 3.3: WONTFIX, 3.4: DONE, 4.0: DONE ruby_4_0 commit:2ab382bd0a86b0012621ebcfbc8f68e91a432197. ---------------------------------------- Bug #11438: native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32 https://bugs.ruby-lang.org/issues/11438#change-119004 * Author: rickerliang (l ly) * Status: Closed * Assignee: windows * ruby -v: 2.2.2 * Backport: 3.3: WONTFIX, 3.4: DONE, 4.0: DONE ---------------------------------------- In function native_thread_init_stack() use VirtualQuery to get thread's stack start address.But some situation(ruby embbed in other application and initial it on the fly),native_thread_init_stack() will be called at low stack address and VirtualQuery return memory info BaseAddress + RegionSize < thread stack base(teb.StackBase). In this situation,subsequently call stack_check() at high stack address will cause stack_overflow exception,because esp > machine.stack_start: (teb.StackLimit < machine.stack_start < esp < teb.StackBase) but actually it is not stack overflow at this time. Use teb.StackBase instead of VirtualQuery get thread stack base is a more reliable solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 14 Sep '26

14 Sep '26

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:126676] [Ruby Bug#22310] parse.y rejects a variable binding that precedes an unrelated alternative pattern
by yuki300 (Yuki Hirota) 14 Sep '26

14 Sep '26

Issue #22310 has been reported by yuki300 (Yuki Hirota). ---------------------------------------- Bug #22310: parse.y rejects a variable binding that precedes an unrelated alternative pattern https://bugs.ruby-lang.org/issues/22310 * Author: yuki300 (Yuki Hirota) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `parse.y` rejects patterns in which a variable binding appears *before* an alternative pattern, even when the alternative itself binds nothing. Prism accepts the same code. Is this intended? ## Reproduction ```ruby # ok.rb case [:a, 1] in [ :a | :b, x ] end # ng.rb case [1, :a] in [ x, :a | :b ] end ``` ``` $ ruby --parser=parse.y -c ok.rb Syntax OK $ ruby --parser=parse.y -c ng.rb ng.rb:2: alternative pattern after variable capture (SyntaxError) $ ruby --parser=prism -c ng.rb Syntax OK ``` The two patterns are semantically identical; only the order of the array elements differs. Both files run without error under the default parser. ## Other forms rejected by parse.y (all accepted by Prism) ```ruby in { a: String => t, b: Integer | String } # binding, then alternative in { a: String => t, b: { c: Integer | String } } # alternative nested deeper in [ one, "a" | "b" => two ] # form reported in rails/bootsnap issue 539 in { access_token: String => token, expires_in: (Integer | String) => expires_in } # form shipped in the anthropic gem ``` Reversing the order makes them pass: ```ruby in { b: Integer | String, a: String => t } # Syntax OK ``` For contrast, a binding *inside* the alternation is rejected by both parsers on 4.0.4, as expected: ```ruby in [ x, :a | y ] # variable capture in alternative pattern (parse.y and Prism) ``` ## Why this looks unintended `:a | :b` and `Integer | String` bind no variables, so the documented restriction -- "Binding to variables currently does NOT work for alternative patterns joined with `|`" -- is not violated. Nothing can be left unbound. The check in `p_alt` tests `p->ctxt.capture_in_pattern`, which is set by any binding anywhere in the same `in` clause, not only by a binding on the left-hand side of the `|`: ```c p_alt : p_alt[left] '|'[alt] { p->ctxt.in_alt_pattern = 1; } p_expr_basic[right] { if (p->ctxt.capture_in_pattern) { yyerror1(&@alt, "alternative pattern after variable capture"); } ``` Prism instead visits the left-hand node when it reaches the `|` (`parse_pattern_alternation_error` in prism.c), so sibling bindings are not affected. The check was introduced in https://github.com/ruby/ruby/commit/f4b6a5191ceb0ed0cd7a3e3c8bab24cc0dd15736 ([Feature #21572]). The discussion in #21572 and in the dev meeting (https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMeeting-2025-10…) only covers bindings *inside* an alternation, and `test/ruby/test_pattern_matching.rb` only asserts the passing order (`in [ :a | :b, x]`). The `p_alt` rule is unchanged on current master. ## Impact Not visible under the default parser. However, `RubyVM::InstructionSequence.compile_file` was routed to parse.y until [Bug #22023] was fixed, so bootsnap (which uses it to build its bytecode cache) made gems fail to load on Ruby 4.0.1-4.0.3 while `ruby foo.rb` worked. That path is fixed in 4.0.4 and worked around in bootsnap 1.24.2, but the parse.y check itself remains. ## Prior sightings The same rejection has been observed before and was each time attributed to the `compile_file` routing bug ([Bug #22023]): - https://github.com/rails/bootsnap/issues/539 (cause identified as https://github.com/ruby/ruby/pull/16463, later backported as #22023) - https://github.com/ruby/irb/issues/1212 ("in Ruby `4.0.2` `parse.y` has a bug, but the important part here is that this is using `parse.y`") - https://github.com/anthropics/anthropic-sdk-ruby/pull/192, whose author noticed that swapping the hash-pattern key order avoids the error As far as I can find, whether the parse.y check itself is correct has not been raised. ## Environment ``` ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] # rejects with --parser=parse.y ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] # same; also via compile_file ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin25] # parse.y accepts all of the above ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126699] [Ruby Bug#22314] parse.y does not check **rest bindings in patterns (duplicate / alternation)
by yuki300 (Yuki Hiro) 14 Sep '26

14 Sep '26

Issue #22314 has been reported by yuki300 (Yuki Hiro). ---------------------------------------- Bug #22314: parse.y does not check **rest bindings in patterns (duplicate / alternation) https://bugs.ruby-lang.org/issues/22314 * Author: yuki300 (Yuki Hiro) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `p_kwrest` is the only binding rule in patterns that does not go through `error_duplicate_pattern_variable`. `p_variable`, `p_rest` and the `{a:}` shorthand in `p_kw` all call it before `assignable`; for `**rest` the name is handed straight to `assignable` in `new_hash_pattern_tail`. So `**rest` is never registered in `pvtbl`, never checked against `in_alt_pattern`, and never sets `capture_in_pattern`. ## Duplicate binding case { a: 1, b: 2 } in { a: x, **x } then p x end $ ruby --parser=parse.y dup.rb {b: 2} # accepted and runs; x is the rest hash $ ruby --parser=prism dup.rb dup.rb:2: duplicated variable name (SyntaxError) `in a, a` and `in a, {a:}` are rejected by parse.y as expected; only `**rest` slips through. This is not a 4.0 regression: parse.y in 3.4.9 also accepts it, and Prism 3.4.9 already rejects it. ## Binding inside an alternative pattern case 1 in 1 | { a: 1, **rest } end $ ruby --parser=parse.y -c alt.rb Syntax OK $ ruby --parser=prism -c alt.rb alt.rb:2: variable capture in alternative pattern (SyntaxError) $ ruby --parser=parse.y alt.rb # compile.c still catches it at run time alt.rb:2: illegal variable in alternative pattern (rest) `*rest` in the same position is rejected at parse time by both parsers. This form only diverges since 4.0, where https://bugs.ruby-lang.org/issues/21572 moved the check to parse time; in 3.4.9 both parsers accept it under `-c` and reject it at compile time. ## Fix Call `error_duplicate_pattern_variable` in `p_kwrest`, as `p_rest` does. One line plus tests: https://github.com/ruby/ruby/pull/18831 It should land after the fix for https://bugs.ruby-lang.org/issues/22310 (https://github.com/ruby/ruby/pull/18830) on its own, making `**rest` set `capture_in_pattern` would newly reject an unrelated sibling alternation such as `in [ { **rest }, 1 | 2 ]` under the current `p_alt` check. With that fix applied first, both parsers agree on every form I tried. Since this turns code parse.y has accepted at least since 3.4 into a SyntaxError, I am not requesting a backport. ## Environment ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] # rejects with --parser=prism only ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin25] # duplicate case: same divergence -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125555] [Ruby Bug#22077] Endless methods in 3.3.5 allows for endless rescues. 4.0 shows different behaviour
by jerome.paul＠gmail.com (Jerome Paul) 14 Sep '26

14 Sep '26

Issue #22077 has been reported by jerome.paul(a)gmail.com (Jerome Paul). ---------------------------------------- Bug #22077: Endless methods in 3.3.5 allows for endless rescues. 4.0 shows different behaviour https://bugs.ruby-lang.org/issues/22077 * Author: jerome.paul(a)gmail.com (Jerome Paul) * Status: Open * ruby -v: 3.4.x * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] ``` irb(main):001> def endless = nil * 1000 rescue raise('surprise') rescue 'please stop' => :endless irb(main):002> endless => "please stop" irb(main):003> ``` ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [x86_64-linux] ``` irb(main):001> def endless = nil * 1000 rescue raise('surprise') rescue 'please stop' => :endless irb(main):002> endless (irb):1:in 'Object#endless': surprise (RuntimeError) from (irb):2:in '<main>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/exe/irb:9:in '<top (required)>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/4.0.0/rubygems.rb:304:in 'Kernel#load' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/4.0.0/rubygems.rb:304:in 'Gem.activate_and_load_bin_path' from /home/jerome/.rbenv/versions/4.0.3/bin/irb:25:in '<main>' (irb):1:in 'Object#endless': undefined method '*' for nil (NoMethodError) from (irb):2:in '<main>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/workspace.rb:110:in 'Kernel#eval' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/workspace.rb:110:in 'IRB::WorkSpace#evaluate' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/context.rb:591:in 'IRB::Context#evaluate_expression' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/context.rb:557:in 'IRB::Context#evaluate' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:202:in 'block (2 levels) in IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:521:in 'IRB::Irb#signal_status' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:194:in 'block in IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:281:in 'block in IRB::Irb#each_top_level_statement' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:278:in 'Kernel#loop' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:278:in 'IRB::Irb#each_top_level_statement' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:193:in 'IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:174:in 'block in IRB::Irb#run' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:173:in 'Kernel#catch' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:173:in 'IRB::Irb#run' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:54:in 'IRB.start' ... 4 levels... ``` `ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux]` shows the same behaviour as 4.0.3. Being honest I don't think endless methods should allow for endless rescues! So the behaviour since at least 3.4.3 is IMO close to correct however instead of a runtime error I would expect a SyntaxError. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117750] [Ruby master Bug#20464] Redundant returns are unreachable in coverage
by kddnewton (Kevin Newton) 14 Sep '26

14 Sep '26

Issue #20464 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20464: Redundant returns are unreachable in coverage https://bugs.ruby-lang.org/issues/20464 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- With the following code: ```ruby def meth_return(a) return if a return end ``` If you run coverage on it, it's not possible for it to hit line 3, because there isn't a line event, because the return node was eliminated from the AST before it was compiled. There is a `putnil` instruction, so it's possible for us to attach a line event for it, but the compiler doesn't today. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:126573] [Ruby Bug#22294] Parsing a long && / || chain is quadratic
by make_now_just (Hiroya Fujinami) 14 Sep '26

14 Sep '26

Issue #22294 has been reported by make_now_just (Hiroya Fujinami). ---------------------------------------- Bug #22294: Parsing a long && / || chain is quadratic https://bugs.ruby-lang.org/issues/22294 * Author: make_now_just (Hiroya Fujinami) * Status: Open * Target version: 4.0 * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Parsing a long chain of short-circuit logical operators (`&&`, `||`, `and`, `or`) takes time that is quadratic in the chain's length. It affects both parsers, parse.y and Prism. ## Reproduction ```ruby require "prism" def bench(label) puts label [2000, 4000, 8000, 16000].each do |n| src = "a" + " && a" * n started = Process.clock_gettime(Process::CLOCK_MONOTONIC) yield src elapsed = Process.clock_gettime(Process::CLOCK_MONOTONIC) - started puts format(" n=%-6d %8.1f ms", n, elapsed * 1000) end end bench("parse.y") { |src| RubyVM::AbstractSyntaxTree.parse(src) } bench("Prism") { |src| Prism.parse(src) } ``` Output on ruby 4.0.4 (arm64-darwin); the time roughly quadruples each time the length doubles: ``` parse.y n=2000 5.7 ms n=4000 22.9 ms n=8000 82.4 ms n=16000 277.0 ms Prism n=2000 4.9 ms n=4000 24.0 ms n=8000 98.5 ms n=16000 368.9 ms ``` `||` / `and` / `or` behave the same. Method chains (`a.b.c...`) and arithmetic (`a + a + ...`) are linear; only the short-circuit logical operators are affected. ## Cause - **parse.y** `logop()`: flattens the left-associative chain into a right-leaning tree, finding the insertion point by walking the whole right branch on every operator (O(n) per operator). - **Prism** `pm_check_value_expression()`: the check descends the left branch of the and/or node (O(n) per operator). ## Note Compiling such chains has a similar issue in the peephole optimizer, which is independent of this parsing issue. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:126689] [Ruby Bug#22313] Bytecode compilation is quadratic in the size of a method due to remove_unreachable_chunk
by make_now_just (Hiroya Fujinami) 14 Sep '26

14 Sep '26

Issue #22313 has been reported by make_now_just (Hiroya Fujinami). ---------------------------------------- Bug #22313: Bytecode compilation is quadratic in the size of a method due to remove_unreachable_chunk https://bugs.ruby-lang.org/issues/22313 * Author: make_now_just (Hiroya Fujinami) * Status: Open * Assignee: make_now_just (Hiroya Fujinami) * Target version: 4.0 * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Compiling one large method whose body contains many unconditional jumps takes time quadratic in the size of the method. ## Reproduction ```ruby def build(units) src = +"def f(x)\n" units.times do |i| src << " while x < #{i}\n x = x + 1\n next if x == #{i}\n break if x > #{i}\n end\n return x if x == #{i}\n" end src << " x\nend\n" end [5_000, 10_000, 20_000].each do |units| src = build(units) t = Process.clock_gettime(Process::CLOCK_MONOTONIC) RubyVM::InstructionSequence.compile(src) printf("%6d units: %5.2f s\n", units, Process.clock_gettime(Process::CLOCK_MONOTONIC) - t) end ``` On `ruby 4.1.0dev (2026-09-14T06:17:27Z master d973aef325) +PRISM [arm64-darwin25]` (Apple M1 Pro): ``` 5000 units: 0.25 s 10000 units: 1.08 s 20000 units: 4.38 s ``` Doubling the method's size quadruples the compile time. Ruby 4.0.4 behaves the same. ## Cause `remove_unreachable_chunk` in `compile.c` allocates a counter array sized by the method's label count and clears it on every call: ```c int *unref_counts = 0, nlabels = ISEQ_COMPILE_DATA(iseq)->label_no; if (!i) return 0; unref_counts = ALLOCA_N(int, nlabels); MEMZERO(unref_counts, int, nlabels); ``` `iseq_peephole_optimize` calls it for every unconditional jump and leave it visits, and both the number of those calls and label_no grow linearly with the method, so the MEMZERO alone costs O(jumps x labels) per method. A profile of the reproduction spends most of its compile time in `__bzero` under `iseq_peephole_optimize` -> `remove_unreachable_chunk`. As a side note, `ALLOCA_N` is also unbounded: a method with tens of thousands of labels puts hundreds of kilobytes on the C stack per call. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126687] [Ruby Feature#22312] Add parent directory operations and recursive file removal
by nobu (Nobuyoshi Nakada) 14 Sep '26

14 Sep '26

Issue #22312 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22312: Add parent directory operations and recursive file removal https://bugs.ruby-lang.org/issues/22312 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose extending `Dir.mkdir`, `Dir.rmdir`, and `File.unlink` with options for operating on directory trees. These operations currently require `FileUtils`; providing them in core would also allow recursive removal to improve robustness by using native directory descriptors or Windows handles where available. ## Proposed API ````ruby Dir.mkdir(path, permissions = 0777, perm: permissions, parents: false) Dir.rmdir(path, parents: false, ignore_non_empty: false) File.unlink(*paths, recursive: false) ```` The aliases `Dir.delete`, `Dir.unlink`, and `File.delete` receive the corresponding options. Calls without the new options retain their existing behavior. ## Creating parent directories `Dir.mkdir(path, parents: true)` creates missing parent directories and returns `0` if the target is already a directory. An existing non-directory raises an exception. ````ruby Dir.mkdir("build/cache/objects", parents: true, perm: 0700) # => 0 ```` The requested permissions apply only to the final directory. New parents use `0777`, subject to the process umask, and existing directories keep their permissions. Permissions remain ignored on Windows. ## Removing empty parent directories `Dir.rmdir(path, parents: true)` removes the target and then successive empty parents. It does not remove a filesystem root or the relative parent path `.`. Its return value remains `0`. The `ignore_non_empty:` option controls when removal stops successfully: | Value | Target directory | Parent directories | |-------------------|--------------------------------|-----------------------------------------------------| | `false` (default) | Raise if non-empty | Raise if non-empty | | `true` | Stop successfully if non-empty | Stop successfully if non-empty | | `:parents` | Require successful removal | Stop successfully if non-empty or no longer present | Other errors raise exceptions. `:parents` matches the error handling of `FileUtils.rmdir(path, parents: true)` and has no effect without `parents: true`. Removal already completed is not rolled back on an error. ````ruby Dir.rmdir("build/cache/objects", parents: true, ignore_non_empty: :parents) ```` Parent removal currently uses path-based calls to `rmdir`, resolving the path again at each step. It does not guarantee protection against concurrent renames or symbolic-link substitution in intermediate path components. Such changes can redirect removal to unintended empty directories that the process has permission to remove. Avoid using this option where another process can modify the path concurrently. Retaining descriptors for all ancestors would require a number of descriptors proportional to the path depth. Walking upward with `openat(fd, "..")` would bound descriptor usage, but could follow a directory into a different parent after a concurrent rename. The current proposal retains path-based parent removal with the limitation described above. ## Recursive removal `File.unlink(*paths, recursive: true)` also removes directories and their contents. It returns the number of supplied paths, rather than the number of entries removed. ````ruby File.unlink("build/cache", recursive: true) # => 1 ```` Symbolic links at the target, including targets specified with trailing slashes, and links inside the tree are removed without traversing their targets in the absence of concurrent replacement. Filesystem roots and paths ending in `.` or `..` are rejected. Like `FileUtils.rm_r` with its default `force: false`, this option does not suppress errors: missing paths and other failures raise exceptions, possibly after partial removal. The implementation uses descriptor-relative operations, including `openat` and `unlinkat`, on platforms supporting them. Opened directories remain accessible through their descriptors if renamed during traversal, so their contents may still be removed after a rename. Concurrent modifications can cause an exception; the operation is not atomic. Mounted filesystems inside the tree are traversed on non-Windows platforms. On Windows, the implementation retains directory handles with sharing disabled and removes entries through their handles. Reparse points in the ancestor path are rejected; reparse points at or inside the target are removed without traversal. Existing handles that conflict with exclusive access cause an error. On other platforms, a path-based fallback behaves similarly to `FileUtils.remove_entry`. It cannot prevent traversal through a symbolic link substituted concurrently for a directory, so it is unsuitable for trees another process can modify concurrently. ## Possible `force:` option An additional `force: false` keyword for `File.unlink` may be useful for cleanup operations. Combined with `recursive: true`, it could cover use cases currently served by `FileUtils.rm_rf`. This option is not implemented in the current patch. The scope of error suppression needs discussion: should `force: true` ignore only missing paths, or suppress removal errors more broadly as `FileUtils.rm_r(force: true)` does? Its applicability without `recursive: true` and the return value when some supplied paths cannot be removed also need to be defined. ## Implementation [Implementation branch](https://github.com/nobu/ruby/tree/recursive-file-operations) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126590] [Ruby Bug#22298] IO::Buffer is left unfreed with an invalid pointer when fiber scheduler raises
by hanazuki (Kasumi Hanazuki) 14 Sep '26

14 Sep '26

Issue #22298 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #22298: IO::Buffer is left unfreed with an invalid pointer when fiber scheduler raises https://bugs.ruby-lang.org/issues/22298 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-06T12:40:34Z master e536482403) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When an installed Fiber scheduler raises from its I/O hook, the temporary IO::Buffer passed to the hook is left unfreed. The buffer may then outlive the memory it wraps, so accessing it afterward can cause undefined behavior. This only happens when the buffer escapes from the I/O callback, which is supposed to be a bug in the scheduler, but I think it is worth fixing silent memory corruption. ```ruby class Scheduler def block(*) = Fiber.yield def unblock(*) = nil def kernel_sleep(*) = nil def io_wait(*) = 0 def fiber_interrupt(*) = nil def fiber(&block) Fiber.new(blocking: false, &block).tap(&:transfer) end def io_write(io, buffer, offset, length) $escape = buffer # This buffer wraps a borrowed temporary memory fail end end r, w = IO.pipe Fiber.set_scheduler(Scheduler.new) Fiber.schedule { w.write('hello') } rescue nil GC.start p $escape # .inspect will read freed memory ``` -- https://bugs.ruby-lang.org/

2 2