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

[ruby-core:123386] [Ruby Bug#21624] [BUG] Segmentation fault at 0x0000000000000000
by mriffe (Mel Riffe) 03 Oct '25

03 Oct '25

Issue #21624 has been reported by mriffe (Mel Riffe). ---------------------------------------- Bug #21624: [BUG] Segmentation fault at 0x0000000000000000 https://bugs.ruby-lang.org/issues/21624 * Author: mriffe (Mel Riffe) * Status: Open * ruby -v: ruby 3.3.9 (2025-07-24 revision f5c772fc7c) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The attached file contains the core dump I receive running `bin/rake db:setup` in a Ruby on Rails project. I'm looking for help on where the actual problem lies. Any assistance will be appreciated. **Background** I'm moving from a Mac Book Pro to an Ubuntu (24.04) Desktop, as my daily development machine. At first I suspected the `mysql2` gem, so I uninstalled it, and installed it again. I verified I have `libmysqlclient-dev` installed; I figure the gem wouldn't compile without the headers but I wanted to be sure. I do not have experience debugging core dumps/segmentation faults. Instruction would be greatly appreciated. What additional information can I provide to aid running down and solving this issue? Plus, if this is not the location for this notification, kindly point me in the right direction. Thank you for your time and energy. ---Files-------------------------------- error.out (381 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123389] [Ruby Feature#21625] Allow IO#wait_readable together with IO#ungetc
by YO4 (Yoshinao Muramatsu) 03 Oct '25

03 Oct '25

Issue #21625 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #21625: Allow IO#wait_readable together with IO#ungetc https://bugs.ruby-lang.org/issues/21625 * Author: YO4 (Yoshinao Muramatsu) * Status: Open ---------------------------------------- ### Background IO#wait_readable calles rb_io_check_byte_readable() in that C implementation, so that is treated as binary reading class operation. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); f.wait_readable } # => in 'IO#wait_readable': byte oriented read for character buffered IO (IOError) ``` This is inconsistent with the behavior of IO#select. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); IO.select([f]) } # => [[#<File:NUL (closed)>], [], []] ``` ### Proposal Change IO#wait_readable into character reading class function. This allows mixing usage of IO#wait_readable and IO#ungetc. This change avoids the IOError that previously occurred, but in that case, an exception is thrown when the binary read method is subsequently called. Overall behavior remains unchanged, but exceptions will occur at more desirable locations. If the method being called next is a character method, no exception will be thrown. But that is the desired behavior. ### related methods IO#io_wait_priority may apply similar changes for consistency. IO#ready? seems to have the same issue. This is in the io-wait default gem. IO#wait already respects the character read buffer. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123375] [Ruby Bug#21622] Prism wrongly accepts command call to be a key of keyword argument
by tompng (tomoya ishida) 03 Oct '25

03 Oct '25

Issue #21622 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21622: Prism wrongly accepts command call to be a key of keyword argument https://bugs.ruby-lang.org/issues/21622 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-02T03:48:32Z master 88222caaa9) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These are syntax error in parse.y but accepted in Prism ~~~ruby p(p a, x: b => value) p(p a, x: => value) p(p a, &block => value) p(p a, *args => value) p(p a, **kwargs => value) ~~~ Maybe as a result, Prism accepts command call within command call ~~~ruby p p 1, &block => 2, &block p p p 1 => 2 => 3 => 4 ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123383] [Ruby Bug#21623] Endless method definition without parenthesis is wrongly accepted in Prism
by tompng (tomoya ishida) 03 Oct '25

03 Oct '25

Issue #21623 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21623: Endless method definition without parenthesis is wrongly accepted in Prism https://bugs.ruby-lang.org/issues/21623 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-02T03:48:32Z master 88222caaa9) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These are syntax error in parse.y but accepted in Prism ~~~ruby def f x: = 1 def f ... = 1 def f * = 1 def f ** = 1 def f & = 1 def f *a = 1 def f **a = 1 def f &a = 1 ~~~ -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123350] [Ruby Bug#21618] Allow to use the build-in prism version to parse code
by Earlopain (Earlopain _) 03 Oct '25

03 Oct '25

Issue #21618 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21618: Allow to use the build-in prism version to parse code https://bugs.ruby-lang.org/issues/21618 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism is a multi-version parser, which is a great feature. If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would. Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences. `ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself. Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect. It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`. It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself. @kddnewton does this feature request make sense? Do you have any other ideas/inputs? -- https://bugs.ruby-lang.org/

4 10

[ruby-core:123360] [Ruby Bug#21620] master branch: LTO with >= -O2 optimization causes miniruby to segfault in vm_cc
by jprokop (Jarek Prokop) 03 Oct '25

03 Oct '25

Issue #21620 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #21620: master branch: LTO with >= -O2 optimization causes miniruby to segfault in vm_cc https://bugs.ruby-lang.org/issues/21620 * Author: jprokop (Jarek Prokop) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby built with LTO (`-flto`) with the -O2 or -O3 optimization causes misbehavior in miniruby. Using -O1 does not result in segfault. Higher optimization is required. Removing `-flto` results in no segfault. Preview1 was OK, after running git-bisect I arrived at the following commit hash: [547f111b5b0d773af2a4268fe407fdacc7060109](https://github.com/ruby/ruby/comm… as the culprit that introduced the buggy behavior. Latest tested commit [3361aa5c7df35b1d1daea578fefec3addf29c9a6](https://github.com/ruby/ruby/comm… still exhibits this behavior. ``` $ export CFLAGS='-O2 -flto -g' $ ./autogen.sh $ ./configure $ ./make -j16 V=1 <...snip...> ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -o builtin_binary.rbbin \ ./template/builtin_binary.rbbin.tmpl make: *** [uncommon.mk:1363: builtin_binary.rbbin] Segmentation fault (core dumped) ``` Supplied also -g to have debug info available in GDB Once miniruby is linked and available to run, simplest reproducer is just `./miniruby`, that is enough for a segfault. This segfault was observed with following GCC versions as delivered on Fedora/RHEL: * Fedora 42: 15.2.1 * RHEL 10: 14.3.1 * RHEL 9: 11.5.0 There are different backtraces with different `O` optimization levels. The following backtraces are from the mentioned commit `547f111b5b0d773af2a4268fe407fdacc7060109` With -O2 ``` $ gdb ./miniruby (gdb) run Starting program: /home/fedora/projects/ruby/miniruby [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. vm_lookup_cc (klass=klass@entry=140737348630880, ci=ci@entry=0x7fffffffe450, mid=mid@entry=4161) at /home/fedora/projects/ruby/vm_insnhelper.c:2173 2173 const int ccs_len = ccs->len; (gdb) bt f #0 vm_lookup_cc (klass=klass@entry=140737348630880, ci=ci@entry=0x7fffffffe450, mid=mid@entry=4161) at /home/fedora/projects/ruby/vm_insnhelper.c:2173 ccs_len = 1 vm_locking_level = <optimized out> vm_locking_do = <optimized out> flag = <optimized out> i = <optimized out> ccs_ci_flag = <optimized out> ccs_cc = <optimized out> argc = <optimized out> ccs_ci_argc = <optimized out> cc_tbl = 140737348956800 ccs = 0x555555b88aa0 #1 0x00005555557bc6d6 in vm_search_cc (klass=140737348630880, ci=0x7fffffffe450) at /home/fedora/projects/ruby/vm_insnhelper.c:2220 mid = 4161 cc = <optimized out> #2 0x00005555557cf48e in rb_vm_search_method_slowpath (ci=<optimized out>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2247 cc = <optimized out> #3 vm_search_method_slowpath0 (cd_owner=0, cd=<synthetic pointer>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2266 cc = <optimized out> empty_cc = <optimized out> cc = <optimized out> empty_cc = <optimized out> #4 gccct_method_search_slowpath (vm=0x555555b6d310, klass=<optimized out>, index=200, ci=<optimized out>) at /home/fedora/projects/ruby/vm_eval.c:418 cd = <optimized out> #5 0x00005555557d899a in gccct_method_search (ec=0x555555b74390, recv=140737348632000, mid=4161, ci=0x7fffffffe450) at /home/fedora/projects/ruby/vm_eval.c:490 cc = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> cc = <optimized out> cme = <optimized out> #6 rb_funcallv_scope (recv=140737348632000, mid=4161, argc=<optimized out>, argv=0x7fffffffe538, scope=CALL_FCALL) at /home/fedora/projects/ruby/vm_eval.c:1059 ec = 0x555555b74390 ci = {flags = 106522, kwarg = 0x0, mid = 4161, flag = 4, argc = 1} cc = <optimized out> self = <optimized out> #7 0x000055555558fc50 in rb_funcallv (recv=140737348632000, mid=<optimized out>, argc=1, argv=0x7fffffffe538) at /home/fedora/projects/ruby/vm_eval.c:1080 No locals. #8 rb_class_inherited (super=super@entry=140737348632000, klass=klass@entry=140737348629120) at /home/fedora/projects/ruby/class.c:1472 rb_funcall_argc = 1 rb_funcall_args = {140737348629120} rb_funcall_nargs = 1 inherited = <optimized out> rbimpl_id = 4161 #9 0x000055555558fd6a in rb_define_class (name=<optimized out>, super=140737348632000) at /home/fedora/projects/ruby/class.c:1506 klass = 140737348629120 id = 5163 ns = <optimized out> #10 0x00005555556af895 in InitVM_Object () at /home/fedora/projects/ruby/object.c:4606 No locals. #11 0x00005555556498ff in Init_Object () at /home/fedora/projects/ruby/object.c:4639 No locals. #12 rb_call_inits () at /home/fedora/projects/ruby/inits.c:29 No locals. #13 0x0000555555613e10 in ruby_setup () at /home/fedora/projects/ruby/eval.c:87 _ec = 0x555555b74390 _tag = {tag = 36, retval = 3, buf = {0x7fffffffe948, 0x5555556132f8 <ruby_setup+872>, 0x7fffffffe6c0, 0x8800, 0x0}, prev = 0x0, state = RUBY_TAG_NONE, lock_rec = 0} state = RUBY_TAG_NONE #14 0x0000555555613fa9 in ruby_init () at /home/fedora/projects/ruby/eval.c:99 state = <optimized out> ec = <optimized out> #15 0x00005555555689e2 in rb_main (argc=1, argv=0x7fffffffe948) at ./main.c:41 variable_in_this_stack_frame = 0 #16 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:62 No locals. ``` With -O3, there it fails at different point, so backtrace is different, for completeness this was configured with `export CFLAGS="-O3 -flto -g"`: ``` (gdb) run Starting program: /home/fedora/projects/ruby/miniruby [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffde5ff6c0 (LWP 519565)] Thread 1 "miniruby" received signal SIGSEGV, Segmentation fault. vm_ccs_push (cc_tbl=140737348956800, ccs=0x555555cc6ae0, ci=0x7fffffffd090, cc=0x7ffff7a7ea28) at /home/fedora/projects/ruby/vm_insnhelper.c:2006 2006 if (UNLIKELY(ccs->len == ccs->capa)) { Missing rpms, try: dnf --enablerepo='*debug*' install libxcrypt-debuginfo-4.4.38-7.fc41.x86_64 glibc-debuginfo-2.40-28.fc41.x86_64 libgcc-debuginfo-14.3.1-3.fc41.x86_64 (gdb) bt f #0 vm_ccs_push (cc_tbl=140737348956800, ccs=0x555555cc6ae0, ci=0x7fffffffd090, cc=0x7ffff7a7ea28) at /home/fedora/projects/ruby/vm_insnhelper.c:2006 pos = <optimized out> pos = <optimized out> #1 vm_populate_cc (klass=140737348630880, ci=0x7fffffffd090, mid=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2146 original_cc_table = 140737348956800 ccs = 0x555555cc6ae0 cme = 0x7ffff7acd128 cc = 0x7ffff7a7ea28 cc_tbl = 140737348956800 cc_tbl = <optimized out> original_cc_table = <optimized out> ccs = <optimized out> cme = <optimized out> cc = <optimized out> #2 vm_search_cc (klass=140737348630880, ci=0x7fffffffd090) at /home/fedora/projects/ruby/vm_insnhelper.c:2233 vm_locking_level = 21845 vm_locking_do = <optimized out> mid = <optimized out> cc = <optimized out> #3 0x000055555583508e in rb_vm_search_method_slowpath (ci=<optimized out>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2247 cc = <optimized out> #4 vm_search_method_slowpath0 (cd_owner=140737348407160, cd=<synthetic pointer>, klass=<optimized out>) at /home/fedora/projects/ruby/vm_insnhelper.c:2266 cc = <optimized out> empty_cc = <optimized out> cc = <optimized out> empty_cc = <optimized out> #5 gccct_method_search_slowpath (vm=0x555555bee310, klass=<optimized out>, index=377, ci=<optimized out>) at /home/fedora/projects/ruby/vm_eval.c:418 cd = <optimized out> #6 0x00005555558cf0fd in gccct_method_search (ec=0x555555bf5390, recv=140737348632000, mid=2865, ci=0x7fffffffd090) at /home/fedora/projects/ruby/vm_eval.c:490 cc = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> klass = <optimized out> ns_value = <optimized out> ns = <optimized out> index = <optimized out> vm = <optimized out> cc = <optimized out> cme = <optimized out> #7 rb_funcallv_scope.constprop.0 (recv=140737348632000, mid=2865, argc=1, argv=0x7fffffffd108, scope=CALL_FCALL) at /home/fedora/projects/ruby/vm_eval.c:1059 ec = 0x555555bf5390 ci = {flags = 106522, kwarg = 0x0, mid = 2865, flag = 4, argc = 1} cc = <optimized out> self = <optimized out> #8 0x0000555555816885 in rb_funcallv (argc=1, recv=140737348632000, mid=2865, argv=0x7fffffffd108) at /home/fedora/projects/ruby/vm_eval.c:1076 No locals. #9 const_added (klass=140737348632000, const_name=30875) at /home/fedora/projects/ruby/variable.c:4000 name = 7904012 #10 const_added (klass=140737348632000, const_name=30875) at /home/fedora/projects/ruby/variable.c:3996 name = <optimized out> #11 rb_const_set (klass=140737348632000, id=30875, val=140737348364880) at /home/fedora/projects/ruby/variable.c:4074 No locals. #12 rb_define_const (klass=140737348632000, name=name@entry=0x555555aff318 "RUBY_DESCRIPTION", val=val@entry=140737348364880) at /home/fedora/projects/ruby/variable.c:4176 id = 30875 #13 0x00005555558169ec in rb_define_global_const (name=0x555555aff318 "RUBY_DESCRIPTION", val=140737348364880) at /home/fedora/projects/ruby/variable.c:4180 No locals. #14 define_ruby_const (mod=140737348467520, name=0x555555aff318 "RUBY_DESCRIPTION", value=140737348364880, toplevel=true) at /home/fedora/projects/ruby/version.c:103 No locals. #15 define_ruby_description (jit_opt=<optimized out>) at /home/fedora/projects/ruby/version.c:243 n = 76 mRuby = 140737348467520 description = 140737348364880 desc = "ruby 3.5.0dev (2025-08-01T08:42:04Z master 547f111b5b) +PRISM [x86_64-linux]\000\000\000\000\000\000\000\000\000\000" #16 0x0000555555783cac in Init_ruby_description (opt=0x8) at /home/fedora/projects/ruby/version.c:253 jit_opt = <optimized out> jit_opt = <optimized out> #17 process_options (argc=<optimized out>, argc@entry=1, argv=<optimized out>, argv@entry=0x7fffffffe948, opt=opt@entry=0x7fffffffe680) at /home/fedora/projects/ruby/ruby.c:2378 ast_value = 4 result = {ast = 0x0, prism = {parser = {node_id = 0, lex_state = PM_LEX_STATE_NONE, enclosure_nesting = 0, lambda_enclosure_nesting = 0, brace_nesting = 0, do_loop_stack = 0, accepts_block_stack = 0, lex_modes = {current = 0x0, stack = {{mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}, {mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, --Type <RET> for more, q to quit, c to continue without paging-- interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}, {mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}, {mode = PM_LEX_DEFAULT, as = {list = {nesting = 0, interpolation = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000\000\000\000\000"}, regexp = {nesting = 0, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, string = {nesting = 0, interpolation = false, label_allowed = false, incrementor = 0 '\000', terminator = 0 '\000', breakpoints = "\000\000\000\000\000\000"}, heredoc = {base = {ident_start = 0x0, ident_length = 0, quote = PM_HEREDOC_QUOTE_NONE, indent = PM_HEREDOC_INDENT_NONE}, next_start = 0x0, common_whitespace = 0x0, line_continuation = false}}, prev = 0x0}}, index = 0}, start = 0x0, end = 0x0, previous = {type = 0, start = 0x0, end = 0x0}, current = {type = 0, start = 0x0, end = 0x0}, next_start = 0x0, heredoc_end = 0x0, comment_list = {size = 0, head = 0x0, tail = 0x0}, magic_comment_list = {size = 0, head = 0x0, tail = 0x0}, data_loc = {start = 0x0, end = 0x0}, warning_list = {size = 0, head = 0x0, tail = 0x0}, error_list = {size = 0, head = 0x0, tail = 0x0}, current_scope = 0x0, current_context = 0x0, current_hash_keys = 0x0, encoding = 0x0, encoding_changed_callback = 0x0, encoding_comment_start = 0x0, lex_callback = 0x0, filepath = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, constant_pool = {buckets = 0x0, constants = 0x0, size = 0, capacity = 0}, newline_list = {start = 0x0, size = 0, capacity = 0, offsets = 0x0}, integer_base = 0, current_string = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, start_line = 0, explicit_encoding = 0x0, current_block_exits = 0x0, version = PM_OPTIONS_VERSION_UNSET, command_line = 0 '\000', frozen_string_literal = 0 '\000', parsing_eval = false, partial_script = false, command_start = false, recovering = false, encoding_locked = false, encoding_changed = false, pattern_matching_newlines = false, in_keyword_arg = false, semantic_token_seen = false, current_regular_expression_ascii_only = false, warn_mismatched_indentation = false}, options = {shebang_callback = 0x0, shebang_callback_data = 0x0, filepath = { source = 0x0, length = 0, type = PM_STRING_CONSTANT}, line = 0, encoding = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, scopes_count = 0, scopes = 0x0, version = PM_OPTIONS_VERSION_UNSET, command_line = 0 '\000', frozen_string_literal = 0 '\000', encoding_locked = false, main_script = false, partial_script = false, freeze = false}, input = {source = 0x0, length = 0, type = PM_STRING_CONSTANT}, node = {base = {type = 0, flags = 0, node_id = 0, location = { start = 0x0, end = 0x0}}, previous = 0x0, ast_node = 0x0, parameters = 0x0, body = 0x0, locals = {size = 0, capacity = 0, ids = 0x0}, parser = 0x0, encoding = 0x0, script_lines = 0x0, filepath_encoding = 0x0, local_table_for_iseq_size = 0, constants = 0x0, index_lookup_table = 0x0, coverage_enabled = 0, pre_execution_anchor = 0x0}, parsed = false}} iseq = <optimized out> enc = <optimized out> lenc = <optimized out> s = <optimized out> fbuf = "\300\317\033\000\000\000\000\000\000\004\000\000\000\000\000\000\260\327\377\377\377\177\000\000\030\022\337\367\377\177\000\000\020\327\373\367\377\177\000\000|\353\336\367\377\177\000\000\201\031\236|\000\000\000\000\020:\340\367\377\177\000\000p\327\377\377\377\177\000\000\033\002\375\367\377\177\000\000\257\002\000\000\000\000\000\000\020:\340\367\377\177\000\000\020\327\373\367\377\177\000\0008\327\377\377\377\177\000\0004\327\377\377\377\177\000\000\235\340\026\000\000\000\000\000\235\340\026\000\000\000\000\000\000\020\000\000\000\000\000\000\001\000\000\000\004\000\000\000\000\000\027\000\000\000\000\000\000\000\027", '\000' <repeats 13 times>, "\006\000\000\000\000\000\000\000(\335\373\367\377\177\000\000\030\330\377\377\377\177\000\000"... i = <optimized out> dump = <optimized out> vm = 0x555555bee310 loaded_before_enc = 8 rbimpl_id = 0 #18 0x000055555578604d in ruby_process_options (argc=1, argv=0x7fffffffe948) at /home/fedora/projects/ruby/ruby.c:222 opt = {script = 0x0, script_name = 0, e_script = 0, src = {enc = {name = 0, index = -1}}, ext = {enc = {name = 0, index = -1}}, intern = {enc = {name = 0, index = -1}}, req_list = 0, features = {mask = 0, set = 31}, warn = {mask = 0, set = 0}, dump = 8, backtrace_length_limit = -9223372036854775808, crash_report = 0x0, sflag = 0, xflag = 0, warning = 0, verbose = 0, do_loop = 0, do_print = 0, do_line = 0, do_split = 0, do_search = 0, setids = 0, yjit = 0} iseq = <optimized out> script_name = <optimized out> #19 0x0000555555628844 in ruby_options (argc=<optimized out>, argv=<optimized out>) at /home/fedora/projects/ruby/eval.c:118 _ec = 0x555555bf5390 _tag = {tag = 36, retval = 34816, buf = {0x7fffffffe948, 0x55555562886a <ruby_options+186>, 0x7fffffffe740, 0x68dd1020, 0x0}, prev = 0x0, state = RUBY_TAG_NONE, lock_rec = 0} ec = 0x555555bf5390 state = RUBY_TAG_NONE iseq = 0x0 #20 0x0000555555569d2c in rb_main (argc=1, argv=0x7fffffffe948) at ./main.c:42 variable_in_this_stack_frame = 0 #21 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:62 ``` This time there is also Ruby's segfault handler, with -O2 it doesn't reach that stage: ``` $ ./miniruby ./miniruby: [BUG] Segmentation fault at 0x0000000000000004 ruby 3.5.0dev (2025-08-01T08:42:04Z master 547f111b5b) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:001460 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055609bc1cb7c RBP: 0x0000000000000000 RSP: 0x00007ffda4c6ad10 RAX: 0x0000000000000000 RBX: 0x00007ffda4c6add0 RCX: 0x0000000000000000 RDX: 0x000000000000b01a RDI: 0x0000000000000000 RSI: 0x00007f729eb5e998 R8: 0x0000000000000000 R9: 0x00007f72a07fd130 R10: 0x0000000000000000 R11: 0x00007f729eb5e998 R12: 0x00007f72a07ef968 R13: 0x00007f729eb5e998 R14: 0x00007f72b9c4f288 R15: 0x0000000000000000 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /home/fedora/projects/ruby/miniruby(0x55609bc515d5) [0x55609bc515d5] /home/fedora/projects/ruby/miniruby(0x55609bc556cf) [0x55609bc556cf] /home/fedora/projects/ruby/miniruby(0x55609ba2554c) [0x55609ba2554c] /home/fedora/projects/ruby/miniruby(0x55609bb9d462) [0x55609bb9d462] /lib64/libc.so.6(__restore_rt+0x0) [0x7f72b9dd8450] /home/fedora/projects/ruby/miniruby(0x55609bc1cb7c) [0x55609bc1cb7c] /home/fedora/projects/ruby/miniruby(0x55609bc3d08e) [0x55609bc3d08e] /home/fedora/projects/ruby/miniruby(0x55609bcd70fd) [0x55609bcd70fd] /home/fedora/projects/ruby/miniruby(0x55609bc1e885) [0x55609bc1e885] /home/fedora/projects/ruby/miniruby(0x55609bc1e9ec) [0x55609bc1e9ec] /home/fedora/projects/ruby/miniruby(0x55609bb8bcac) [0x55609bb8bcac] /home/fedora/projects/ruby/miniruby(0x55609bb8e04d) [0x55609bb8e04d] /home/fedora/projects/ruby/miniruby(0x55609ba30844) [0x55609ba30844] /home/fedora/projects/ruby/miniruby(0x55609b971d2c) [0x55609b971d2c] /lib64/libc.so.6(__libc_start_call_main+0x78) [0x7f72b9dc1448] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7f72b9dc150b] [0x55609b971d65] -- Other runtime information ----------------------------------------------- * Loaded script: ./miniruby * 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 * Process memory map: 55609b95c000-55609b95d000 r--p 00000000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609b95d000-55609bdfa000 r-xp 00001000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bdfa000-55609bfc7000 r--p 0049e000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bfc7000-55609bfdd000 r--p 0066a000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bfdd000-55609bfdf000 rw-p 00680000 00:26 193598 /home/fedora/projects/ruby/miniruby 55609bfdf000-55609bff4000 rw-p 00000000 00:00 0 5560c4356000-5560c4449000 rw-p 00000000 00:00 0 [heap] 7f729b600000-7f729b858000 r--s 00000000 00:26 131829 /usr/lib64/libc.so.6 7f729ba00000-7f729ea29000 r--s 00000000 00:26 193598 /home/fedora/projects/ruby/miniruby 7f729eb50000-7f729eb60000 rw-p 00000000 00:00 0 7f729eb6f000-7f729eb70000 ---p 00000000 00:00 0 7f729eb70000-7f729ec11000 rw-p 00000000 00:00 0 7f729ec11000-7f729ec12000 ---p 00000000 00:00 0 7f729ec12000-7f729ecb3000 rw-p 00000000 00:00 0 7f729ecb3000-7f729ecb4000 ---p 00000000 00:00 0 7f729ecb4000-7f729ed55000 rw-p 00000000 00:00 0 7f729ed55000-7f729ed56000 ---p 00000000 00:00 0 7f729ed56000-7f729edf7000 rw-p 00000000 00:00 0 7f729edf7000-7f729edf8000 ---p 00000000 00:00 0 7f729edf8000-7f729ee99000 rw-p 00000000 00:00 0 7f729ee99000-7f729ee9a000 ---p 00000000 00:00 0 7f729ee9a000-7f729ef3b000 rw-p 00000000 00:00 0 7f729ef3b000-7f729ef3c000 ---p 00000000 00:00 0 7f729ef3c000-7f729efdd000 rw-p 00000000 00:00 0 7f729efdd000-7f729efde000 ---p 00000000 00:00 0 7f729efde000-7f729f07f000 rw-p 00000000 00:00 0 7f729f07f000-7f729f080000 ---p 00000000 00:00 0 7f729f080000-7f729f121000 rw-p 00000000 00:00 0 7f729f121000-7f729f122000 ---p 00000000 00:00 0 7f729f122000-7f729f1c3000 rw-p 00000000 00:00 0 7f729f1c3000-7f729f1c4000 ---p 00000000 00:00 0 7f729f1c4000-7f729f265000 rw-p 00000000 00:00 0 7f729f265000-7f729f266000 ---p 00000000 00:00 0 7f729f266000-7f729f307000 rw-p 00000000 00:00 0 7f729f307000-7f729f308000 ---p 00000000 00:00 0 7f729f308000-7f729f3a9000 rw-p 00000000 00:00 0 7f729f3a9000-7f729f3aa000 ---p 00000000 00:00 0 7f729f3aa000-7f729f44b000 rw-p 00000000 00:00 0 7f729f44b000-7f729f44c000 ---p 00000000 00:00 0 7f729f44c000-7f729f4ed000 rw-p 00000000 00:00 0 7f729f4ed000-7f729f4ee000 ---p 00000000 00:00 0 7f729f4ee000-7f729f58f000 rw-p 00000000 00:00 0 7f729f58f000-7f729f590000 ---p 00000000 00:00 0 7f729f590000-7f729f631000 rw-p 00000000 00:00 0 7f729f631000-7f729f632000 ---p 00000000 00:00 0 7f729f632000-7f729f6d3000 rw-p 00000000 00:00 0 7f729f6d3000-7f729f6d4000 ---p 00000000 00:00 0 7f729f6d4000-7f729f775000 rw-p 00000000 00:00 0 7f729f775000-7f729f776000 ---p 00000000 00:00 0 7f729f776000-7f729f817000 rw-p 00000000 00:00 0 7f729f817000-7f729f818000 ---p 00000000 00:00 0 7f729f818000-7f729f8b9000 rw-p 00000000 00:00 0 7f729f8b9000-7f729f8ba000 ---p 00000000 00:00 0 7f729f8ba000-7f729f95b000 rw-p 00000000 00:00 0 7f729f95b000-7f729f95c000 ---p 00000000 00:00 0 7f729f95c000-7f729f9fd000 rw-p 00000000 00:00 0 7f729f9fd000-7f729f9fe000 ---p 00000000 00:00 0 7f729f9fe000-7f729fa9f000 rw-p 00000000 00:00 0 7f729fa9f000-7f729faa0000 ---p 00000000 00:00 0 7f729faa0000-7f729fb41000 rw-p 00000000 00:00 0 7f729fb41000-7f729fb42000 ---p 00000000 00:00 0 7f729fb42000-7f729fbe3000 rw-p 00000000 00:00 0 7f729fbe3000-7f729fbe4000 ---p 00000000 00:00 0 7f729fbe4000-7f729fc85000 rw-p 00000000 00:00 0 7f729fc85000-7f729fc86000 ---p 00000000 00:00 0 7f729fc86000-7f729fd27000 rw-p 00000000 00:00 0 7f729fd27000-7f729fd28000 ---p 00000000 00:00 0 7f729fd28000-7f729fdc9000 rw-p 00000000 00:00 0 7f729fdc9000-7f729fdca000 ---p 00000000 00:00 0 7f729fdca000-7f729fe6b000 rw-p 00000000 00:00 0 7f729fe6b000-7f729fe6c000 ---p 00000000 00:00 0 7f729fe6c000-7f729ff0d000 rw-p 00000000 00:00 0 7f729ff0d000-7f729ff0e000 ---p 00000000 00:00 0 7f729ff0e000-7f729ffaf000 rw-p 00000000 00:00 0 7f729ffaf000-7f729ffb0000 ---p 00000000 00:00 0 7f729ffb0000-7f72a07b0000 rw-p 00000000 00:00 0 7f72a07b0000-7f72b9c00000 rw-p 00000000 00:00 0 7f72b9c1f000-7f72b9c50000 rw-p 00000000 00:00 0 7f72b9c58000-7f72b9d59000 rw-p 00000000 00:00 0 7f72b9d59000-7f72b9d60000 r--s 00000000 00:26 150886 /usr/lib64/gconv/gconv-modules.cache 7f72b9d60000-7f72b9db9000 r--p 00000000 00:26 131283 /usr/lib/locale/C.utf8/LC_CTYPE 7f72b9db9000-7f72b9dbe000 rw-p 00000000 00:00 0 7f72b9dbe000-7f72b9dbf000 r--p 00000000 00:26 131829 /usr/lib64/libc.so.6 7f72b9dbf000-7f72b9f2e000 r-xp 00001000 00:26 131829 /usr/lib64/libc.so.6 7f72b9f2e000-7f72b9fa3000 r--p 00170000 00:26 131829 /usr/lib64/libc.so.6 7f72b9fa3000-7f72b9fa7000 r--p 001e5000 00:26 131829 /usr/lib64/libc.so.6 7f72b9fa7000-7f72b9fa9000 rw-p 001e9000 00:26 131829 /usr/lib64/libc.so.6 7f72b9fa9000-7f72b9fb1000 rw-p 00000000 00:00 0 7f72b9fb1000-7f72b9fb2000 r--p 00000000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fb2000-7f72b9fd6000 r-xp 00001000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fd6000-7f72b9fde000 r--p 00025000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fde000-7f72b9fdf000 r--p 0002c000 00:26 131249 /usr/lib64/libgcc_s-14-20250808.so.1 7f72b9fdf000-7f72b9fe0000 rw-p 00000000 00:00 0 7f72b9fe0000-7f72b9fe1000 r--p 00000000 00:26 131831 /usr/lib64/libm.so.6 7f72b9fe1000-7f72ba05a000 r-xp 00001000 00:26 131831 /usr/lib64/libm.so.6 7f72ba05a000-7f72ba0c4000 r--p 0007a000 00:26 131831 /usr/lib64/libm.so.6 7f72ba0c4000-7f72ba0c5000 r--p 000e3000 00:26 131831 /usr/lib64/libm.so.6 7f72ba0c5000-7f72ba0c6000 rw-p 000e4000 00:26 131831 /usr/lib64/libm.so.6 7f72ba0c6000-7f72ba0c7000 r--p 00000000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0c7000-7f72ba0e0000 r-xp 00001000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0e0000-7f72ba0fa000 r--p 0001a000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0fa000-7f72ba0fb000 r--p 00033000 00:26 57774 /usr/lib64/libcrypt.so.2.0.0 7f72ba0fb000-7f72ba0fc000 rw-p 00000000 00:00 0 7f72ba100000-7f72ba101000 rw-p 00000000 00:00 0 7f72ba101000-7f72ba102000 rw-p 00000000 00:00 0 7f72ba102000-7f72ba104000 rw-p 00000000 00:00 0 7f72ba104000-7f72ba108000 r--p 00000000 00:00 0 [vvar] 7f72ba108000-7f72ba10a000 r--p 00000000 00:00 0 [vvar_vclock] 7f72ba10a000-7f72ba10c000 r-xp 00000000 00:00 0 [vdso] 7f72ba10c000-7f72ba10d000 r--p 00000000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba10d000-7f72ba136000 r-xp 00001000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba136000-7f72ba141000 r--p 0002a000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba141000-7f72ba143000 r--p 00035000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7f72ba143000-7f72ba145000 rw-p 00037000 00:26 131826 /usr/lib64/ld-linux-x86-64.so.2 7ffda4c4c000-7ffda4c6d000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Segmentation fault (core dumped) ``` Once it gets to the segfault, I can reproduce the line/lookup without causing more crashing and the values are available, not sure what's up or if it crashes on the correct line in the debugger. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:123207] [Ruby Bug#21568] Requiring core libraries when already requiring mutliple user defined libraries with the same name can error
by alexalexgriffith (Alex Griffith) 02 Oct '25

02 Oct '25

Issue #21568 has been reported by alexalexgriffith (Alex Griffith). ---------------------------------------- Bug #21568: Requiring core libraries when already requiring mutliple user defined libraries with the same name can error https://bugs.ruby-lang.org/issues/21568 * Author: alexalexgriffith (Alex Griffith) * Status: Open * ruby -v: ruby 3.1.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The simplest way to understand this error is that after requiring 2 or more files with the same name as some core libraries, any subsequent calls to require the core library will fail, ie ```ruby require '/Users/alex/foo/fiber' require '/Users/alex/bar/fiber' require 'fiber' ``` raises ``` cannot load such file -- fiber ``` More detailed instructions to repro this can be found in the code snippet below. Noting that I am on a Mac, OS 15.6. This is reproducible across my team on a few different OS versions, all Mac. The same underlying issue can also be seen in some other issues like: https://github.com/newrelic/newrelic-ruby-agent/issues/2001 The context this error is discovered in is that some gems may require their own libraries with the same name as core libraries, often wrapping the implementations of those core libraries to extend functionality, like the New Relic ruby agent does with fiber, for example (https://github.com/newrelic/newrelic-ruby-agent/tree/dev/lib/new_relic/agen…) Then, if 2 or more gems do something like that, and any other gem has `require 'fiber'` in it to support old ruby versions where this was necessary, the error occurs. **Full Steps to Reproduce:** ``` ruby # Setup # ===== # 1. Set this base_dir variable to be an absolute path to a dir # or something that can be found in your $LOAD_PATH. base_dir = # ex: "/Users/<you>/ruby_require_test" # 2. Within that base directory create 2 directories named `foo` and `bar` # 3. Within both `foo` and `bar` touch new files named # - complex.rb # - enumerator.rb # - fiber.rb # - rational.rb # - ruby2_keywords.rb # - set.rb # - thread.rb # Note - this list was generated by running: # `ruby -ve 'p $LOADED_FEATURES.reject { |feature| %r|/| =~ feature }'` # which returns: `["enumerator.so", "thread.rb", "fiber.so", "rational.so", "complex.so", "ruby2_keywords.rb"]` # Reproducing the error: # After requiring 2 (or more) user defined files with the same name as part of # the ruby core library that is required as a bare filename, requiring that part of # the core library will error, ex: `cannot load such file -- fiber`. # The erroring require statements are all .so files begin require "#{base_dir}/foo/complex" require "#{base_dir}/bar/complex" require 'complex' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/enumerator" require "#{base_dir}/bar/enumerator" require 'enumerator' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/fiber" require "#{base_dir}/bar/fiber" require 'fiber' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/rational" require "#{base_dir}/bar/rational" require 'rational' rescue LoadError => e puts e.message end # The following examples do not error. # The difference seems to be that the core lib files are defined as .rb not .so begin require "#{base_dir}/foo/ruby2_keywords" require "#{base_dir}/bar/ruby2_keywords" require 'ruby2_keywords' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/set" require "#{base_dir}/bar/set" require 'set' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/thread" require "#{base_dir}/bar/thread" require 'thread' rescue LoadError => e puts e.message end ``` -- https://bugs.ruby-lang.org/

3 6

[ruby-core:121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only)
by LocoDelAssembly 01 Oct '25

01 Oct '25

Issue #21187 has been reported by LocoDelAssembly (Hernán Pereira). ---------------------------------------- Bug #21187: Strings concatenated with `\` getting frozen with literal hashes (PRISM only) https://bugs.ruby-lang.org/issues/21187 * Author: LocoDelAssembly (Hernán Pereira) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When the first elements of a literal hash are strings that are concatenated with `\`, those elements are flagged with `PM_NODE_FLAG_STATIC_LITERAL` and a special optimization that I believe was introduced in https://github.com/ruby/ruby/commit/8080de04be8e99e71309745822a9d436cc4ae37c causes the strings to be frozen. Reproduction === test.rb ``` a = { a: 'one' \ 'two', b: 'three' \ 'four', c: 'five', d: 'six' \ 'seven' } b = { a: 'one', b: 'two' \ 'three' } puts "a = #{a.map { |k,v| {k => v.frozen?} }}" puts "b = #{b.map { |k,v| {k => v.frozen?} }}" ``` With prism: ``` $ ruby test.rb a = [{a: true}, {b: true}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` With parse.y: ``` $ ruby --parser=parse.y test.rb a = [{a: false}, {b: false}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` (Notice `b` hash is unaffected in both parsers) Not sure if this is just part of undefined behavior or this is indeed a bug. Assigning a string concatenated with `\` to a variable doesn't make it frozen, to the best of my knowledge this seems to be hash-specific. -- https://bugs.ruby-lang.org/

6 8

[ruby-core:123257] [Ruby Misc#21606] DevMeeting-2025-10-23
by mame (Yusuke Endoh) 01 Oct '25

01 Oct '25

Issue #21606 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21606: DevMeeting-2025-10-23 https://bugs.ruby-lang.org/issues/21606 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/10/23 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/10/20. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123362] [Ruby Bug#21621] test-bundled-gems.rb timeouts with csv gem on ci
by YO4 (Yoshinao Muramatsu) 01 Oct '25

01 Oct '25

Issue #21621 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21621: test-bundled-gems.rb timeouts with csv gem on ci https://bugs.ruby-lang.org/issues/21621 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Github Actions workflow ```Windows 2025/Visual C++ 2022 (test-bundled-gems)``` has a timeout issue for csv gem. That timeout seems to have been missed for months. The following was recorded in a successful test. ``` Testing the csv gem D:/a/ruby/ruby/build/ruby.exe -C D:/a/ruby/ruby/src/gems/src/csv D:/a/ruby/ruby/src/.bundle/bin/rake test Sending KILL signal ``` This should record a failure in the test for the csv gem. With git bisect, I found the first bad is f30f0f0a22bb5cf536b5ca551f3dfa5ebb745030. It was also reproduced locally when using the mingw compiler. But I couldn't discover any more about this issue. It is another issue that test-bundled-gems.rb correctly recognizes timeouts as failures. I created a [PR14695](https://github.com/ruby/ruby/pull/14695) for that. -- https://bugs.ruby-lang.org/

1 0