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

[ruby-core:124412] [Ruby Bug#21817] Ruby::Box crashes with refinement + bind_call + Symbol#to_proc combination
by ahogappa (sho hirano) 02 Jan '26

02 Jan '26

Issue #21817 has been reported by ahogappa (sho hirano). ---------------------------------------- Bug #21817: Ruby::Box crashes with refinement + bind_call + Symbol#to_proc combination https://bugs.ruby-lang.org/issues/21817 * Author: ahogappa (sho hirano) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description When running with `RUBY_BOX=1`, a combination of refinement on Binding class, `bind_call`, and `Symbol#to_proc` causes a crash with the error: `[BUG] BUG: Local ep without cme/box, flags: 66660087` ## Reproduction Script ```ruby # Run with: RUBY_BOX=1 ruby repro.rb using Module.new { refine ::Binding do def eval_methods ::Kernel.instance_method(:methods).bind_call(receiver) end end } p binding.eval_methods.map(&:to_s) ``` ## Expected Behavior The script should return an array of method names as strings. ## Actual Behavior Ruby crashes with `[BUG] BUG: Local ep without cme/box, flags: 66660087` ## Workaround Using block form instead of Symbol#to_proc does not crash: ```ruby binding.eval_methods.map { it.to_s } # This works ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123959] [Ruby Feature#21721] Allow `Queue` and `SizedQueue` to be used as LIFO queues
by byroot (Jean Boussier) 31 Dec '25

31 Dec '25

Issue #21721 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21721: Allow `Queue` and `SizedQueue` to be used as LIFO queues https://bugs.ruby-lang.org/issues/21721 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context Since `Queue` and `SizedQueue` gained a proper timeout mechanism, I've been wanting to use them to implement simpler and more efficient connection pools. However for connection pools you ideally want a LIFO queue because it's preferable to checkout the most recently used connection. ### Problem Both `Queue` and `SizedQueue` only support FIFO because you can only enqueue elements at the beginning of the backing array, and only dequeue at the end. `Queue#push` (aliased as `Queue#<<` and `Queue#enq`) calls `Array#unshift` on the backing array and `Queue#pop` (aliased as `Queue#deq` and `Queue#shift`) calls `Array#pop`. Hence it is impossible to use these two classes for anything other than FIFO queues. I tried to use `git blame` to see if there was a justification for this, but I ended up in a git blame loop around May 2000 https://github.com/ruby/ruby/commit/9da4f78db46764be6dae5e7e83ff48cbecb3fb23 ### Feature I'd like to introduce either of two new methods (or both) to allow for LIFO: - A method to dequeue from the beginning of the backing array (`array_shift`). - A method to enqueue from the end of the backing array (`array_push`). A difficulty I have however is that since the common `shift/pop/push` terms are already used with uncommon meaning, it's hard to come up with good names. Ideas welcome. ### Possible alternatives - Define different classes for LIFO queues - But I find that less flexible, and it means exposing new constant names in the global namespace. - Add an initializer argument to define the queue ordering, e.g. `Queue.new([], lifo: true)` - Similarly, I find this less flexible than to decide the order during enqueue/dequeue - Add an argument to `Queue#pop` and `Queue#push`, e.g. `queue.push(element, front: true)`. -- https://bugs.ruby-lang.org/

6 21

[ruby-core:124410] [Ruby Feature#8948] Frozen regex
by Eregon (Benoit Daloze) 31 Dec '25

31 Dec '25

Issue #8948 has been updated by Eregon (Benoit Daloze). matz (Yukihiro Matsumoto) wrote in #note-35: > I still do not see enough benefit in putting in incompatible changes. Even if we can rewrite all the gems, we will still have incompatibility issues in user applications. It seems extremely unlikely that applications subclass Regexp, or add instance variables to Regexps (which already doesn't work for literal Regexps). I would expect something like maybe 1 application in a million do that. The benefits are: * Non-literal Regexps are frozen too, which means they can be used with Ractor. * Simplicity for the semantics and users: all Regexps are frozen, not "some Regexps are frozen" and some not, when the internal state of a Regexp has always been immutable anyway. * Improved compatibility between Ruby implementations. The cons are: * A few gems out of ~188000 gems seem affected. It's not complicated to update the code to avoid relying on mutable Regexps (there is no need to subclass Regexp, one can just delegate the relevant methods). * A few applications might be affected. * In either case, I expect this potential incompatibility won't be noticed by 99.9+% users. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115928 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124407] [Ruby Feature#8948] Frozen regex
by matz (Yukihiro Matsumoto) 31 Dec '25

31 Dec '25

Issue #8948 has been updated by matz (Yukihiro Matsumoto). Eregon (Benoit Daloze) wrote in #note-34: > @matz Is it OK to merge https://github.com/ruby/ruby/pull/14547 now for 4.1? I still do not see enough benefit in putting in incompatible changes. Even if we can rewrite all the gems, we will still have incompatibility issues in user applications. Matz. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115925 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124401] [Ruby Feature#8948] Frozen regex
by Eregon (Benoit Daloze) 30 Dec '25

30 Dec '25

Issue #8948 has been updated by Eregon (Benoit Daloze). @matz Is it OK to merge https://github.com/ruby/ruby/pull/14547 now for 4.1? Then there is plenty of time for the few gems that rely on mutable Regexp to adapt. BTW I noticed someone else also did a PR for this, so there seems to be some interest: https://github.com/ruby/ruby/pull/15762 ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115919 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124207] [Ruby Bug#21784] Proc#source_location start column seems strange for -> {}
by Eregon (Benoit Daloze) 30 Dec '25

30 Dec '25

Issue #21784 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21784: Proc#source_location start column seems strange for -> {} https://bugs.ruby-lang.org/issues/21784 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'p -> { a }.source_location' ["-e", 1, 4, 1, 10] ``` So it considers the stabby lambda to be at: ```ruby p -> { a }.source_location ^^^^^^ ``` Note it starts at a whitespace after the `->`. I think it should just include the `->`, i.e. return `["-e", 1, 2, 1, 10]`. Or possibly start at the `{`, i.e. return `["-e", 1, 3, 1, 10]`. But starting on a whitespace like here seems really strange, it looks like a bug. It's the same result with `--parser=parse.y`, so I don't show it. --- For context: For Procs/block it looks like this: ``` $ ruby -e 'p proc { a }.source_location' ["-e", 1, 7, 1, 12] ``` ```ruby p proc { a }.source_location ^^^^^ ``` This looks fine. The block could of course be given to any other method so it won't always be `proc` in front. Maybe it could include the method too (so it would return start column 2 here), I think either is fine. For `for` blocks it looks like this: ``` $ ruby -e ' def self.each(&b); yield b; end; for b in self 42 end p b.source_location' ["-e", 3, 0, 5, 3] ``` That is, it covers the entire `for` expression from `for` until `end`. I think that's good and fine as-is. For `def` methods it covers everything from `def` to `end` (or end of line for `def m = 42`), as expected. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:124206] [Ruby Bug#21783] {Method,UnboundMethod,Proc}#source_location returns columns in bytes and not in characters
by Eregon (Benoit Daloze) 30 Dec '25

30 Dec '25

Issue #21783 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21783: {Method,UnboundMethod,Proc}#source_location returns columns in bytes and not in characters https://bugs.ruby-lang.org/issues/21783 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The documentation says: ``` = Proc.source_location (from ruby core) ------------------------------------------------------------------------ prc.source_location -> [String, Integer, Integer, Integer, Integer] ------------------------------------------------------------------------ Returns the location where the Proc was defined. The returned Array contains: (1) the Ruby source filename (2) the line number where the definition starts (3) the column number where the definition starts (4) the line number where the definition ends (5) the column number where the definitions ends This method will return nil if the Proc was not defined in Ruby (i.e. native). ``` So it talks about column numbers, so it should be a number of characters and not of bytes. But currently it's a number of bytes: ``` $ ruby --parser=prism -ve 'def été; end; p method(:été).source_location' ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) +PRISM [x86_64-linux] ["-e", 1, 0, 1, 14] ruby --parser=parse.y -ve 'def été; end; p method(:été).source_location' ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) [x86_64-linux] ["-e", 1, 0, 1, 14] ``` The last number should be 12 because `"def été; end".size` is 12 characters. This is a Ruby-level API so I would never expect "byte columns" here, I think it's clear it should be a number of "editor columns" i.e. a number of characters. -- https://bugs.ruby-lang.org/

5 21

[ruby-core:120749] [Ruby master Feature#21084] Declare objects have weak references
by peterzhu2118 (Peter Zhu) 30 Dec '25

30 Dec '25

Issue #21084 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #21084: Declare objects have weak references https://bugs.ruby-lang.org/issues/21084 * Author: peterzhu2118 (Peter Zhu) * Status: Open ---------------------------------------- # Summary The current way of marking weak references uses `rb_gc_mark_weak(VALUE *ptr)`. This presents challenges because Ruby's GC is incremental, meaning that if the `ptr` changes (e.g. realloc'd or free'd), then we could have an invalid memory access. This also overwrites `*ptr = Qundef` if `*ptr` is dead, which prevents any cleanup to be run (e.g. freeing memory or deleting entries from hash tables). This ticket proposes `rb_gc_declare_weak_references` which declares that an object has weak references and calls a cleanup function after marking, allowing the object to clean up any memory for dead objects. # Introduction In [[Feature #19783]](https://bugs.ruby-lang.org/issues/19783), I introduced an API allowing objects to mark weak references, the function signature looks like this: ```c void rb_gc_mark_weak(VALUE *ptr); ``` `rb_gc_mark_weak` is called during the marking phase of the GC to specify that the memory at `ptr` holds a pointer to a Ruby object that is weakly referenced. `rb_gc_mark_weak` appends this pointer to a list that is processed after the marking phase of the GC. If the object at `*ptr` is no longer alive, then it overwrites the object reference with a special value (`*ptr = Qundef`). However, this API resulted in two challenges: 1. Ruby's default GC is incremental, which means that the GC is not ran in one phase, but rather split into chunks of work that interleaves with Ruby execution. The `ptr` passed into `rb_gc_mark_weak` could be on the malloc heap, and that memory could be realloc'd or even free'd. We had to use workarounds such as `rb_gc_remove_weak` to ensure that there were no illegal memory accesses. This made `rb_gc_mark_weak` difficult to use, impacted runtime performance, and increased memory usage. 2. When an object dies, `rb_gc_mark_weak` only overwites the reference with `Qundef`. This means that if we want to do any cleanup (e.g. free a piece of memory or delete a hash table entry), we could not do that and had to defer this process elsewhere (e.g. during marking or runtime). # Declarative weak references In this ticket, I'm proposing a new API for weak references. Instead of an object marking its weak references during the marking phase, the object declares that it has weak references using the `rb_gc_declare_weak_references` function. This declaration occurs during runtime (e.g. after the object has been created) rather than during GC. After an object declares that it has weak references, it will have its callback function called after marking as long as that object is alive. This callback function can then call a special function `rb_gc_handle_weak_references_alive_p` to determine whether its references are alive. This will allow the callback function to do whatever it wants on the object, allowing it to perform any cleanup work it needs. This significantly simplifies the code for `ObjectSpace::WeakMap` and `ObjectSpace::WeakKeyMap` because it no longer needs to have the workarounds for the limitations of `rb_gc_mark_weak`. # Performance The performance results below demonstrate that `ObjectSpace::WeakMap#[]=` is now about 60% faster because the implementation has been simplified and the number of allocations has been reduced. We can see that there is not a significant impact on the performance of `ObjectSpace::WeakMap#[]`. Base: ``` ObjectSpace::WeakMap#[]= 4.620M (± 6.4%) i/s (216.44 ns/i) - 23.342M in 5.072149s ObjectSpace::WeakMap#[] 30.967M (± 1.9%) i/s (32.29 ns/i) - 154.998M in 5.007157s ``` Branch: ``` ObjectSpace::WeakMap#[]= 7.336M (± 2.8%) i/s (136.31 ns/i) - 36.755M in 5.013983s ObjectSpace::WeakMap#[] 30.902M (± 5.4%) i/s (32.36 ns/i) - 155.901M in 5.064060s ``` Code: ``` require "bundler/inline" gemfile do source "https://rubygems.org" gem "benchmark-ips" end wmap = ObjectSpace::WeakMap.new key = Object.new val = Object.new wmap[key] = val Benchmark.ips do |x| x.report("ObjectSpace::WeakMap#[]=") do |times| i = 0 while i < times wmap[Object.new] = Object.new i += 1 end end x.report("ObjectSpace::WeakMap#[]") do |times| i = 0 while i < times wmap[key] wmap[val] # does not exist i += 1 end end end ``` # Alternative designs Currently, `rb_gc_declare_weak_references` is designed to be an internal-only API. This allows us to assume the object types that call `rb_gc_declare_weak_references`. In the future, if we want to open up this API to third parties, we may want to change this function to something like: ```c void rb_gc_add_cleaner(VALUE obj, void (*callback)(VALUE obj)); ``` This will allow the third party to implement a custom `callback` that gets called after the marking phase of GC to clean up any dead references. I chose not to implement this design because it is less efficient as we would need to store a mapping from `obj` to `callback`, which requires extra memory. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:124315] [Ruby Feature#21797] Make Etc.nprocessors cgroup-aware on Linux
by moznion (Taiki Kawakami) 30 Dec '25

30 Dec '25

Issue #21797 has been reported by moznion (Taiki Kawakami). ---------------------------------------- Feature #21797: Make Etc.nprocessors cgroup-aware on Linux https://bugs.ruby-lang.org/issues/21797 * Author: moznion (Taiki Kawakami) * Status: Open ---------------------------------------- Currently, `Etc.nprocessors` ignores cgroup CPU quotas. This causes issues in containers where CPU limits differ from the host CPU count. I have written a gem for this purpose (https://github.com/moznion/maxprocs-ruby) but it would be preferable if the Ruby core implementation respected cgroup configuration. Additionally, concurrent-ruby provides similar functionality, but if the language itself offered this capability, language users would not need to implement it individually. Extending `Etc.nprocessors` to respect cgroups is one option, but that would be a breaking change, so adding a new API might be a better approach. ## Prior Art - Go 1.25: runtime GOMAXPROCS (Issue [#73193](https://github.com/golang/go/issues/73193)) - [uber-go/automaxprocs](https://github.com/uber-go/automaxprocs) - [concurrent-ruby](https://github.com/ruby-concurrency/concurrent-ruby): https://github.com/ruby-concurrency/concurrent-ruby/blob/129cf004294af68ac5… -- https://bugs.ruby-lang.org/

6 10

[ruby-core:124344] [Ruby Bug#21801] compile failed at 4.0.0 preview 3 and snapshot issue
by darkspy (gerty ken) 29 Dec '25

29 Dec '25

Issue #21801 has been reported by darkspy (gerty ken). ---------------------------------------- Bug #21801: compile failed at 4.0.0 preview 3 and snapshot issue https://bugs.ruby-lang.org/issues/21801 * Author: darkspy (gerty ken) * Status: Open * ruby -v: 4.0.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- compiling x64-msvcrt-ruby400.res.o creating verconf.h verconf.h updated compiling loadpath.c linking static-library libx64-msvcrt-ruby400-static.a generating x64-msvcrt-ruby400.def linking shared-library x64-msvcrt-ruby400.dll generating makefiles ext/configure-ext.mk d:/prog/snapshot-master/tool/lib/output.rb:55: [BUG] rb_maygvl_fd_fix_cloexec: fcntl(3, F_GETFD) failed: Bad file descriptor ruby 4.0.0dev (2025-12-22 master d0ec60dc7b) +PRISM [x64-mingw32] -- Control frame information ----------------------------------------------- c:0004 p:---- s:0034 e:000033 l:y b:---- CFUNC :binwrite c:0003 p:0162 s:0028 e:000027 l:y b:0001 METHOD d:/prog/snapshot-master/tool/lib/output.rb:55 c:0002 p:0107 s:0012 E:000310 l:n b:---- EVAL ./tool/generic_erb.rb:35 [FINISH] c:0001 p:0000 s:0003 E:001080 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- ./tool/generic_erb.rb:35:in '<main>' d:/prog/snapshot-master/tool/lib/output.rb:55:in 'write' d:/prog/snapshot-master/tool/lib/output.rb:55:in 'binwrite' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- C:\Windows\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FFA4A22E9C4] C:\Windows\System32\KERNELBASE.dll(WaitForSingleObjectEx+0x8e) [0x00007FFA47C3E3CE] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0xc2dbb) [0x00000000006F0348] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0xc30a8) [0x00000000006F0635] [0x00000000004CE67C] [0x00000000004CE6FA] [0x0000000000514400] [0x0000000000514581] [0x000000000051FBAC] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x47f73) [0x0000000000675500] [0x000000000051FBE5] [0x000000000051FC77] [0x000000000052028F] [0x0000000000521927] [0x00000000005219C5] [0x00000000005271F0] [0x0000000000527A16] [0x0000000000527B49] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x8f136) [0x00000000006BC6C3] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x8fe42) [0x00000000006BD3CF] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x900b5) [0x00000000006BD642] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x901f0) [0x00000000006BD77D] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x90646) [0x00000000006BDBD3] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x930f1) [0x00000000006C067E] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x93b76) [0x00000000006C1103] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x93d51) [0x00000000006C12DE] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x963d3) [0x00000000006C3960] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0x9e1e8) [0x00000000006CB775] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0xb5eff) [0x00000000006E348C] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0xb5e35) [0x00000000006E33C2] d:\prog\snapshot-master\miniruby.exe(rb_obj_shape_id+0xb6a6e) [0x00000000006E3FFB] [0x00000000004D924D] [0x00000000004D93C0] [0x0000000000401597] [0x00000000004015F8] [0x00000000004015B4] [0x000000000040140F] [0x000000000040154B] C:\Windows\System32\KERNEL32.DLL(BaseThreadInitThunk+0x10) [0x00007FFA498B4ED0] -- Other runtime information ----------------------------------------------- * Loaded script: ./tool/generic_erb.rb * Ruby Box: disabled * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 pathname.so 6 ruby2_keywords.rb 7 set.rb 8 d:/prog/snapshot-master/lib/erb/version.rb 9 d:/prog/snapshot-master/lib/erb/compiler.rb 10 d:/prog/snapshot-master/lib/erb/def_method.rb 11 d:/prog/snapshot-master/lib/cgi/escape.rb 12 d:/prog/snapshot-master/lib/erb/util.rb 13 d:/prog/snapshot-master/lib/erb.rb 14 d:/prog/snapshot-master/lib/optparse.rb 15 d:/prog/snapshot-master/tool/lib/vpath.rb 16 d:/prog/snapshot-master/tool/lib/colorize.rb 17 d:/prog/snapshot-master/tool/lib/output.rb d:/prog/snapshot-master/tool/lib/output.rb:55: [BUG] Aborted ruby 4.0.0dev (2025-12-22 master d0ec60dc7b) +PRISM [x64-mingw32] Crashed while printing bug report make: *** [ext/configure-ext.mk] Error 3 make: *** Deleting file `ext/configure-ext.mk' rm x64-msvcrt-ruby400.rc ------------------------------------ use miniruby or set it to other released version ruby as "--with-baseruby" option or "BOOTSTRAPRUBY" is same error occur. if use miniruby at use tool/mkconfig.rb or generate ext/configure-ext.mk would have chance to occur: Errno::EBADF error at 4.0.0-preview2 was compiled OK. ------------------------------------------ ENV: windows 10~11 msys 1.0 && gcc 7 ~ 12 for test the environment and toolchain is nothing wrong because i compiled 3.1 to 4.0 preview 2 in this environment. -- https://bugs.ruby-lang.org/

3 6