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

[ruby-core:120795] [Ruby master Bug#21090] SEGV from require in Thread in Ractor
by wanabe (_ wanabe) 02 Feb '25

02 Feb '25

Issue #21090 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #21090: SEGV from require in Thread in Ractor https://bugs.ruby-lang.org/issues/21090 * Author: wanabe (_ wanabe) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-18T00:19:17Z origin/master 65a7c69188) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When ruby calls 'require' in Thread in non-main Ractor, it can cause SEGV sometimes. ``` $ ruby -e '1000.times { Ractor.new { th = Thread.new { require "rbconfig" }; Thread.pass }.take }' > segv.log 2>&1 Segmentation fault (core dumped) ``` `segv.log` is too large to paste in this description, so I attached as a file. ---Files-------------------------------- segv.log (36.9 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120774] [Ruby master Bug#21087] "try to mark T_NONE object" error in ActiveRecord with 3.4.1 upgrade
by p8 (Petrik de Heus) 02 Feb '25

02 Feb '25

Issue #21087 has been reported by p8 (Petrik de Heus). ---------------------------------------- Bug #21087: "try to mark T_NONE object" error in ActiveRecord with 3.4.1 upgrade https://bugs.ruby-lang.org/issues/21087 * Author: p8 (Petrik de Heus) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The TechEmpower benchmarks for `rage` fail when setting the `isolation_level` to `:fiber`. The bug can be replicated by checking out [the branch](https://github.com/p8/FrameworkBenchmarks/tree/rage/fiber) and running the following: ```bash ./tfb --test rage --type fortune ``` The error: ``` rage: rb_obj_info_dump: �s�� rage: /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:34: [BUG] try to mark T_NONE object rage: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [aarch64-linux] rage: -- Control frame information ----------------------------------------------- rage: c:0040 p:0007 s:0276 e:000275 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:34 rage: c:0039 p:0003 s:0272 e:000271 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:25 [FINISH] rage: c:0038 p:---- s:0268 e:000267 CFUNC :new rage: c:0037 p:0016 s:0264 e:000260 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:17 rage: c:0036 p:0003 s:0257 e:000256 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:13 rage: c:0035 p:0004 s:0250 e:000249 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_subscriber.rb:13 rage: c:0034 p:0010 s:0243 e:000242 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:162 rage: c:0033 p:0005 s:0239 e:000238 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:25 rage: c:0032 p:0027 s:0234 e:000233 METHOD <internal:array>:228 rage: c:0031 p:0008 s:0228 e:000227 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:24 rage: c:0030 p:0010 s:0222 e:000221 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:122 rage: c:0029 p:0004 s:0217 e:000216 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:161 rage: c:0028 p:0010 s:0210 e:000209 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:259 rage: c:0027 p:0005 s:0206 e:000205 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:25 rage: c:0026 p:0027 s:0201 e:000200 METHOD <internal:array>:228 rage: c:0025 p:0008 s:0195 e:000194 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:24 rage: c:0024 p:0018 s:0189 e:000188 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:258 rage: c:0023 p:0012 s:0182 e:000181 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:251 rage: c:0022 p:0035 s:0178 e:000176 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/instrumenter.rb:64 [FINISH] rage: c:0021 p:0047 s:0169 e:000168 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:1119 [FINISH] rage: c:0020 p:0031 s:0156 e:000155 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:892 rage: c:0019 p:0041 s:0144 e:000143 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:872 rage: c:0018 p:0026 s:0130 e:000129 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:66 rage: c:0017 p:0093 s:0118 e:000117 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:647 rage: c:0016 p:0064 s:0105 e:000104 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:73 [FINISH] rage: c:0015 p:0143 s:0093 e:000092 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/query_cache.rb:251 [FINISH] rage: c:0014 p:0025 s:0080 e:000079 BLOCK /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation/calculations.rb:318 rage: c:0013 p:0030 s:0076 e:000075 METHOD /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/ext/active_record/connection_pool.rb:205 [FINISH] rage: c:0012 p:0011 s:0069 e:000068 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_handling.rb:296 rage: c:0011 p:0022 s:0062 e:000061 BLOCK /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation/calculations.rb:317 rage: c:0010 p:0015 s:0059 e:000058 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation.rb:1452 rage: c:0009 p:0120 s:0054 e:000053 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation/calculations.rb:313 [FINISH] rage: c:0008 p:0012 s:0046 e:000045 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/querying.rb:24 rage: c:0007 p:0008 s:0037 e:000036 METHOD /rage/app/controllers/benchmarks_controller.rb:32 rage: c:0006 p:0038 s:0032 e:000031 METHOD /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/controller/api.rb:98 rage: c:0005 p:0010 s:0028 e:000027 BLOCK (eval at /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/router/backend.rb:79):1 [FINISH] rage: c:0004 p:0043 s:0023 e:000019 METHOD /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/application.rb:16 rage: c:0003 p:0008 s:0011 e:000010 BLOCK /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/middleware/fiber_wrapper.rb:19 [FINISH] rage: c:0002 p:0016 s:0008 e:000005 BLOCK /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/fiber_scheduler.rb:122 [FINISH] rage: c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] rage: -- Ruby level backtrace information --------------------------------------- ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:120830] [Ruby master Bug#21098] rb_alias: confusing error messages when the original method cannot be found and ZSUPER methods are involved
by sanjioh (Fabio Sangiovanni) 30 Jan '25

30 Jan '25

Issue #21098 has been reported by sanjioh (Fabio Sangiovanni). ---------------------------------------- Bug #21098: rb_alias: confusing error messages when the original method cannot be found and ZSUPER methods are involved https://bugs.ruby-lang.org/issues/21098 * Author: sanjioh (Fabio Sangiovanni) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-29T13:19:04Z master 63b6323e04) +PRISM [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi all, I've noticed that the current implementation of `rb_alias` can raise `NameError` exceptions with confusing error messages when the original method cannot be found and ZSUPER methods are involved in the inheritance chain traversal. That's because `rb_print_undef` is invoked with the current value of `klass`, which is repeatedly reassigned whenever a ZSUPER method is encountered in the search, potentially referencing an ICLASS or FALSE. The following are 2 examples of this kind of behavior: ``` ruby module M private :class alias_method :xyz, :class # raises 'Module#alias_method': undefined method 'class' for class 'false' (NameError) end ``` ``` ruby module M private :class end module N prepend M alias_method :xyz, :class # raises 'Module#alias_method': undefined method 'class' for class '#<N:0x0000000124ba7f00>' (NameError) end ``` The second example also triggers an assertion failure when they are enabled with `-DRUBY_DEBUG`: ``` ../vm_insnhelper.c:2192: Assertion Failed: rb_vm_search_method_slowpath:RB_TYPE_2_P(klass, RUBY_T_CLASS, RUBY_T_ICLASS): klass: T_MODULE ``` In the following PR I tried to fix the issue by invoking `rb_print_undef` with `target_klass` as argument, which holds the initial value of `klass`. https://github.com/ruby/ruby/pull/12665 The previous examples become as follows: ``` ruby module M private :class alias_method :xyz, :class # raises 'Module#alias_method': undefined method 'class' for module 'M' (NameError) end ``` ``` ruby module M private :class end module N prepend M alias_method :xyz, :class # raises 'Module#alias_method': undefined method 'class' for module 'N' (NameError) end ``` This is my first contribution to Ruby, so please let me know if I can improve it further. Cheers! -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120650] [Ruby master Bug#21034] try to mark T_NONE object error after upgrading to 3.4.1
by travisbell (Travis Bell) 30 Jan '25

30 Jan '25

Issue #21034 has been reported by travisbell (Travis Bell). ---------------------------------------- Bug #21034: try to mark T_NONE object error after upgrading to 3.4.1 https://bugs.ruby-lang.org/issues/21034 * Author: travisbell (Travis Bell) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi everyone, I noticed we started having some workers crash after upgrading to 3.4.1. I tried grabbing a core file and got this output. Is it enough to figure out what's going on? If not, I can reproduce this fairly easily, so I can grab more debug info if needed. ``` #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44 tid = <optimized out> ret = 0 pd = <optimized out> old_mask = {__val = {2337500343188860976}} ret = <optimized out> pd = <optimized out> old_mask = {__val = {<optimized out>}} ret = <optimized out> tid = <optimized out> ret = <optimized out> resultvar = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> __futex = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> __futex = <optimized out> __private = <optimized out> __oldval = <optimized out> #1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007facb872d26e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = <optimized out> #4 0x00007facb87108ff in __GI_abort () at ./stdlib/abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {2314885530818453536, 2314885530818453536, 6733551554292031520, 3558800716248528650, 7365405400577881908, 3474865974218745190, 2337500343188860976, 3472328296227680304, 3467824696768081952, 2314885530818453536, 2314885530818453536, 2314885530818453536, 6732726843261788192, 62, 18020928395186805760, 140378616593424}}, sa_flags = -1198603040, sa_restorer = 0x7facb8f11b0c} #5 0x00007facb8a9686a in die () at error.c:1071 #6 rb_bug (fmt=fmt@entry=0x7facb8f11b0c "try to mark T_NONE object") at error.c:1095 args = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fac71917450, reg_save_area = 0x7fac71917380}} #7 0x00007facb8b98bee in gc_mark (objspace=0x7facb8072000, obj=140378889836960) at gc/default/default.c:4463 __func__ = {<optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>} #8 gc_mark (obj=140378889836960, objspace=0x7facb8072000) at gc/default/default.c:4443 __func__ = {<optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>} #9 gc_mark_and_pin (obj=140378889836960, objspace=0x7facb8072000) at gc/default/default.c:4489 #10 rb_gc_impl_mark_and_pin (obj=140378889836960, objspace_ptr=0x7facb8072000) at gc/default/default.c:4521 objspace = 0x7facb8072000 objspace = <optimized out> #11 gc_mark_and_pin_internal (obj=140378889836960) at gc.c:2204 vm = <optimized out> objspace = 0x7facb8072000 __func__ = {<optimized out> <repeats 25 times>} vm = <optimized out> objspace = <optimized out> mark_func_data = <optimized out> #12 gc_mark_and_pin_internal (obj=140378889836960) at gc.c:2202 __func__ = {<optimized out> <repeats 25 times>} vm = <optimized out> objspace = <optimized out> mark_func_data = <optimized out> #13 rb_gc_mark_vm_stack_values (n=62, values=0x7fac6ca72000) at gc.c:2291 i = 29 #14 0x00007facb8d6c339 in rb_execution_context_mark (ec=0x7fac803405d0) at vm.c:3404 p = <optimized out> sp = <optimized out> cfp = 0x7fac6ca91d98 limit_cfp = 0x7fac6ca92000 #15 0x00007facb8b4810c in cont_mark (ptr=0x7fac80340580) at cont.c:1011 cont = 0x7fac80340580 cont = <optimized out> #16 fiber_mark (ptr=0x7fac80340580) at cont.c:1140 fiber = 0x7fac80340580 #17 0x00007facb8b9d56d in gc_mark_children (obj=140378344077120, objspace=0x7facb8072000) at gc/default/default.c:4647 #18 gc_mark_stacked_objects (incremental=1, count=4478, objspace=0x7facb8072000) at gc/default/default.c:4668 --Type <RET> for more, q to quit, c to continue without paging-- mstack = 0x7facb8072310 obj = 140378344077120 marked_slots_at_the_beginning = 484361 popped_count = <optimized out> mstack = <optimized out> obj = <optimized out> marked_slots_at_the_beginning = <optimized out> popped_count = <optimized out> #19 gc_mark_stacked_objects_incremental (count=4478, objspace=0x7facb8072000) at gc/default/default.c:4700 #20 gc_marks_step (slots=4478, objspace=0x7facb8072000) at gc/default/default.c:5735 marking_finished = false marking_finished = <optimized out> __func__ = {<optimized out> <repeats 14 times>} #21 gc_marks_continue (heap=0x7facb8072028, objspace=0x7facb8072000) at gc/default/default.c:5755 marking_finished = true __func__ = {<optimized out> <repeats 18 times>} marking_finished = <optimized out> #22 gc_continue (objspace=0x7facb8072000, heap=0x7facb8072028) at gc/default/default.c:2073 lock_lev = 0 #23 0x00007facb8ba0ce2 in newobj_cache_miss (objspace=objspace@entry=0x7facb8072000, cache=cache@entry=0x7facb807c1e0, heap_idx=heap_idx@entry=0, vm_locked=<optimized out>, vm_locked@entry=false) at gc/default/default.c:2414 heap = 0x7facb8072028 obj = 0 lev = 1 unlock_vm = true #24 0x00007facb8ba20e2 in newobj_alloc (vm_locked=false, heap_idx=0, cache=0x7facb807c1e0, objspace=0x7facb8072000) at gc/default/default.c:2447 obj = <optimized out> heap = <optimized out> obj = <optimized out> heap = <optimized out> __func__ = {<optimized out> <repeats 13 times>} #25 rb_gc_impl_new_obj (alloc_size=16, wb_protected=true, v3=0, v2=0, v1=0, flags=8199, klass=140379367216160, cache_ptr=0x7facb807c1e0, objspace_ptr=0x7facb8072000) at gc/default/default.c:2533 obj = <optimized out> objspace = 0x7facb8072000 heap_idx = 0 cache = 0x7facb807c1e0 obj = <optimized out> objspace = <optimized out> heap_idx = <optimized out> cache = <optimized out> cnt = <optimized out> i = <optimized out> #26 newobj_of (size=16, wb_protected=true, v3=0, v2=0, v1=0, flags=8199, klass=140379367216160, cr=0x7facb801e400) at gc.c:984 obj = <optimized out> obj = <optimized out> lev = <optimized out> #27 rb_wb_protected_newobj_of (ec=ec@entry=0x7fac803c97d0, klass=klass@entry=140379367216160, flags=flags@entry=8199, size=size@entry=16) at gc.c:1013 __func__ = {<optimized out> <repeats 26 times>} #28 0x00007facb8aaeda0 in ec_ary_alloc_embed (capa=0, klass=140379367216160, ec=<optimized out>) at array.c:790 size = 16 ary = <optimized out> size = <optimized out> ary = <optimized out> #29 ec_ary_new (capa=0, klass=140379367216160, ec=<optimized out>) at array.c:824 ary = <optimized out> ary = <optimized out> dtrace_line = <optimized out> dtrace_file = <optimized out> #30 rb_ec_ary_new_from_values (ec=<optimized out>, n=0, elts=0x0) at array.c:843 ary = <optimized out> #31 0x00007fac840bd709 in ??? () #32 0x00007fac803c97d0 in ??? () #33 0x0000000000000c61 in ??? () #34 0x00007fac803c9700 in ??? () #35 0x00007facb8d76f98 in jit_exec_exception (ec=<optimized out>) at vm.c:509 func = <optimized out> func = <optimized out> #36 vm_exec_loop (result=<optimized out>, tag=<optimized out>, state=<optimized out>, ec=<optimized out>) at vm.c:2612 vm_loop_start = <optimized out> vm_loop_start = <optimized out> #37 rb_vm_exec (ec=0x7fac803c97d0) at vm.c:2589 _ec = 0x7fac803c97d0 _tag = {tag = 36, retval = 4, buf = {0x0, 0x7facb8d77040 <rb_vm_exec+400>, 0x0, 0x7fac719176f0, 0x0}, prev = 0x7fac71917bd0, state = RUBY_TAG_NONE, lock_rec = 0} state = RUBY_TAG_NONE result = <optimized out> #38 0x00007facb8d7d454 in vm_call0_cc (ec=0x7fac803c97d0, recv=<optimized out>, id=3169, argc=<optimized out>, argv=<optimized out>, cc=<optimized out>, kw_splat=0) at /tmp/ruby-build.20241216235058.18.2gDQPw/ruby-3.4.0-rc1/vm_eval.c:101 --Type <RET> for more, q to quit, c to continue without paging-- flags = <optimized out> use_argv = <optimized out> av = {140378344075280, 140379812157720} calling = {cd = 0x7fac719177c0, cc = 0x7fac8086be90, block_handler = 0, recv = 140378724725520, argc = 1, kw_splat = false, heap_argv = 0} #39 0x00007facb8d80cc5 in rb_call0 (ec=0x7fac803c97d0, recv=recv@entry=140378724725520, mid=mid@entry=3169, argc=argc@entry=1, argv=argv@entry=0x7fac719181f8, call_scope=call_scope@entry=CALL_FCALL, self=140379119115560) at /tmp/ruby-build.20241216235058.18.2gDQPw/ruby-3.4.0-rc1/vm_eval.c:554 call_status = <optimized out> scope = <optimized out> kw_splat = <optimized out> ci = {flags = 110618, kwarg = 0x0, mid = 3169, flag = 4, argc = 1} cc = <optimized out> #40 0x00007facb8d815e6 in rb_call (scope=CALL_FCALL, argv=0x7fac719181f8, argc=1, mid=3169, recv=140378724725520) at /tmp/ruby-build.20241216235058.18.2gDQPw/ruby-3.4.0-rc1/vm_eval.c:873 ec = <optimized out> #41 rb_funcallv_kw (recv=recv@entry=140378724725520, mid=mid@entry=3169, argc=argc@entry=1, argv=argv@entry=0x7fac719181f8, kw_splat=<optimized out>) at /tmp/ruby-build.20241216235058.18.2gDQPw/ruby-3.4.0-rc1/vm_eval.c:1070 #42 0x00007facb8b7d863 in rb_obj_call_init_kw (obj=obj@entry=140378724725520, argc=argc@entry=1, argv=argv@entry=0x7fac719181f8, kw_splat=<optimized out>) at eval.c:1731 #43 0x00007facb8c1d4cc in rb_class_new_instance_pass_kw (argc=1, argv=0x7fac719181f8, klass=140379119115560) at object.c:2175 obj = 140378724725520 #44 0x00007fac842295cb in ??? () #45 0x00007fac71937e78 in ??? () #46 0x0000000000000024 in ??? () #47 0x00007fac803c97d0 in ??? () #48 0x00007facb8d72f2a in vm_exec_core (ec=0x6e2, ec@entry=0x7fac803c97d0) at /tmp/ruby-build.20241216235058.18.2gDQPw/ruby-3.4.0-rc1/insns.def:852 func = 0x0 bh = 140379806001948 cd = 0x7fac803c97d0 blockiseq = 0x6 leaf = <optimized out> val = 140378862557136 reg_pc = 0x7fac980adde0 reg_cfp = 0x7fac71937e78 insns_address_table = {0x7facb8d7019e <vm_exec_core+990>, 0x7facb8d7012a <vm_exec_core+874>, 0x7facb8d700b9 <vm_exec_core+761>, 0x7facb8d70575 <vm_exec_core+1973>, 0x7facb8d704f3 <vm_exec_core+1843>, 0x7facb8d70474 <vm_exec_core+1716>, 0x7facb8d703b1 <vm_exec_core+1521>, 0x7facb8d70658 <vm_exec_core+2200>, 0x7facb8d705f9 <vm_exec_core+2105>, 0x7facb8d702e0 <vm_exec_core+1312>, 0x7facb8d701c8 <vm_exec_core+1032>, 0x7facb8d70ba4 <vm_exec_core+3556>, 0x7facb8d70b57 <vm_exec_core+3479>, 0x7facb8d70af1 <vm_exec_core+3377>, 0x7facb8d70a7c <vm_exec_core+3260>, 0x7facb8d70a37 <vm_exec_core+3191>, 0x7facb8d709f7 <vm_exec_core+3127>, 0x7facb8d709ba <vm_exec_core+3066>, 0x7facb8d7097d <vm_exec_core+3005>, 0x7facb8d70940 <vm_exec_core+2944>, 0x7facb8d708d5 <vm_exec_core+2837>, 0x7facb8d70889 <vm_exec_core+2761>, 0x7facb8d7083a <vm_exec_core+2682>, 0x7facb8d707da <vm_exec_core+2586>, 0x7facb8d7078c <vm_exec_core+2508>, 0x7facb8d70705 <vm_exec_core+2373>, 0x7facb8d706c3 <vm_exec_core+2307>, 0x7facb8d728ab <vm_exec_core+10987>, 0x7facb8d72849 <vm_exec_core+10889>, 0x7facb8d72910 <vm_exec_core+11088>, 0x7facb8d720fa <vm_exec_core+9018>, 0x7facb8d71ef1 <vm_exec_core+8497>, 0x7facb8d71e5b <vm_exec_core+8347>, 0x7facb8d71df5 <vm_exec_core+8245>, 0x7facb8d71d95 <vm_exec_core+8149>, 0x7facb8d71d33 <vm_exec_core+8051>, 0x7facb8d71cde <vm_exec_core+7966>, 0x7facb8d71c62 <vm_exec_core+7842>, 0x7facb8d71c10 <vm_exec_core+7760>, 0x7facb8d71be1 <vm_exec_core+7713>, 0x7facb8d71b9e <vm_exec_core+7646>, 0x7facb8d71b45 <vm_exec_core+7557>, 0x7facb8d71b09 <vm_exec_core+7497>, 0x7facb8d723bf <vm_exec_core+9727>, 0x7facb8d72374 <vm_exec_core+9652>, 0x7facb8d72328 <vm_exec_core+9576>, 0x7facb8d722ee <vm_exec_core+9518>, 0x7facb8d72277 <vm_exec_core+9399>, 0x7facb8d7220d <vm_exec_core+9293>, 0x7facb8d721b6 <vm_exec_core+9206>, 0x7facb8d7213f <vm_exec_core+9087>, 0x7facb8d72621 <vm_exec_core+10337>, 0x7facb8d72506 <vm_exec_core+10054>, 0x7facb8d724c2 <vm_exec_core+9986>, 0x7facb8d72473 <vm_exec_core+9907>, 0x7facb8d72747 <vm_exec_core+10631>, 0x7facb8d72687 <vm_exec_core+10439>, 0x7facb8d6fe30 <vm_exec_core+112>, 0x7facb8d727b9 <vm_exec_core+10745>, 0x7facb8d70d00 <vm_exec_core+3904>, 0x7facb8d71ab2 <vm_exec_core+7410>, 0x7facb8d71a5b <vm_exec_core+7323>, 0x7facb8d73741 <vm_exec_core+14721>, 0x7facb8d71a04 <vm_exec_core+7236>, 0x7facb8d7198d <vm_exec_core+7117>, 0x7facb8d71940 <vm_exec_core+7040>, 0x7facb8d71829 <vm_exec_core+6761>, 0x7facb8d716bc <vm_exec_core+6396>, 0x7facb8d715e4 <vm_exec_core+6180>, 0x7facb8d714e3 <vm_exec_core+5923>, 0x7facb8d72955 <vm_exec_core+11157>, 0x7facb8d7149a <vm_exec_core+5850>, 0x7facb8d71432 <vm_exec_core+5746>, 0x7facb8d713ca <vm_exec_core+5642>, 0x7facb8d71386 <vm_exec_core+5574>, 0x7facb8d712c2 <vm_exec_core+5378>, 0x7facb8d71237 <vm_exec_core+5239>, 0x7facb8d73978 <vm_exec_core+15288>, 0x7facb8d73c7c <vm_exec_core+16060>, 0x7facb8d73cea <vm_exec_core+16170>, 0x7facb8d730bc <vm_exec_core+13052>, 0x7facb8d73d8b <vm_exec_core+16331>, 0x7facb8d73b5c <vm_exec_core+15772>, 0x7facb8d73bba <vm_exec_core+15866>, 0x7facb8d734ca <vm_exec_core+14090>, 0x7facb8d73530 <vm_exec_core+14192>, 0x7facb8d73596 <vm_exec_core+14294>, 0x7facb8d73687 <vm_exec_core+14535>, 0x7facb8d735fc <vm_exec_core+14396>, 0x7facb8d736ed <vm_exec_core+14637>, 0x7facb8d731f9 <vm_exec_core+13369>, 0x7facb8d73254 <vm_exec_core+13460>, 0x7facb8d739e7 <vm_exec_core+15399>, 0x7facb8d7118a <vm_exec_core+5066>, 0x7facb8d710de <vm_exec_core+4894>, 0x7facb8d73b0c <vm_exec_core+15692>, 0x7facb8d73793 <vm_exec_core+14803>, 0x7facb8d737e3 <vm_exec_core+14883>, 0x7facb8d73895 <vm_exec_core+15061>, 0x7facb8d73903 <vm_exec_core+15171>, 0x7facb8d73a79 <vm_exec_core+15545>, 0x7facb8d71065 <vm_exec_core+4773>, 0x7facb8d70fdd <vm_exec_core+4637>, 0x7facb8d70f1d <vm_exec_core+4445>, 0x7facb8d70ece <vm_exec_core+4366>, 0x7facb8d70e7b <vm_exec_core+4283>, 0x7facb8d70e2a <vm_exec_core+4202>, 0x7facb8d70dd1 <vm_exec_core+4113>, 0x7facb8d70d94 <vm_exec_core+4052>, 0x7facb8d70d57 <vm_exec_core+3991>, 0x7facb8d7018d <vm_exec_core+973>, 0x7facb8d70119 <vm_exec_core+857>, 0x7facb8d700a8 <vm_exec_core+744>, 0x7facb8d70564 <vm_exec_core+1956>, 0x7facb8d704e2 <vm_exec_core+1826>, 0x7facb8d70463 <vm_exec_core+1699>, 0x7facb8d703a0 <vm_exec_core+1504>, 0x7facb8d70647 <vm_exec_core+2183>, 0x7facb8d705e8 <vm_exec_core+2088>, 0x7facb8d702cf <vm_exec_core+1295>, 0x7facb8d701b7 <vm_exec_core+1015>, 0x7facb8d70b93 <vm_exec_core+3539>, 0x7facb8d70b46 <vm_exec_core+3462>, 0x7facb8d70ae0 <vm_exec_core+3360>, 0x7facb8d70a6b <vm_exec_core+3243>, 0x7facb8d70a26 <vm_exec_core+3174>, 0x7facb8d709e6 <vm_exec_core+3110>, 0x7facb8d709a9 <vm_exec_core+3049>, 0x7facb8d7096c <vm_exec_core+2988>, 0x7facb8d7092f <vm_exec_core+2927>, 0x7facb8d708c4 <vm_exec_core+2820>, 0x7facb8d70878 <vm_exec_core+2744>, 0x7facb8d70829 <vm_exec_core+2665>, 0x7facb8d707c9 <vm_exec_core+2569>, 0x7facb8d7077b <vm_exec_core+2491>, 0x7facb8d706f4 <vm_exec_core+2356>, 0x7facb8d706b2 <vm_exec_core+2290>, 0x7facb8d7289a <vm_exec_core+10970>, 0x7facb8d72838 <vm_exec_core+10872>, 0x7facb8d728ff <vm_exec_core+11071>, 0x7facb8d720e9 <vm_exec_core+9001>, 0x7facb8d71ee0 <vm_exec_core+8480>, 0x7facb8d71e4a <vm_exec_core+8330>, 0x7facb8d71de4 <vm_exec_core+8228>, 0x7facb8d71d84 <vm_exec_core+8132>, 0x7facb8d71d22 <vm_exec_core+8034>, 0x7facb8d71ccd <vm_exec_core+7949>, 0x7facb8d71c51 <vm_exec_core+7825>, 0x7facb8d71bff <vm_exec_core+7743>, 0x7facb8d71bd0 <vm_exec_core+7696>, 0x7facb8d71b8d <vm_exec_core+7629>, 0x7facb8d71b34 <vm_exec_core+7540>, 0x7facb8d71af8 <vm_exec_core+7480>, 0x7facb8d723ae <vm_exec_core+9710>, 0x7facb8d72363 <vm_exec_core+9635>, 0x7facb8d72317 <vm_exec_core+9559>, 0x7facb8d722dd <vm_exec_core+9501>, 0x7facb8d72266 <vm_exec_core+9382>, 0x7facb8d721fc <vm_exec_core+9276>, 0x7facb8d721a5 <vm_exec_core+9189>, 0x7facb8d7212e <vm_exec_core+9070>, 0x7facb8d72610 <vm_exec_core+10320>, 0x7facb8d724f5 <vm_exec_core+10037>, 0x7facb8d724b1 <vm_exec_core+9969>, 0x7facb8d72462 <vm_exec_core+9890>, 0x7facb8d72736 <vm_exec_core+10614>, 0x7facb8d72676 <vm_exec_core+10422>, 0x7facb8d732df <vm_exec_core+13599>, 0x7facb8d727a8 <vm_exec_core+10728>, 0x7facb8d70cef <vm_exec_core+3887>, 0x7facb8d71aa1 <vm_exec_core+7393>, 0x7facb8d71a4a <vm_exec_core+7306>, 0x7facb8d732f5 <vm_exec_core+13621>, 0x7facb8d719f3 <vm_exec_core+7219>, 0x7facb8d7197c <vm_exec_core+7100>, 0x7facb8d7192f <vm_exec_core+7023>, 0x7facb8d71818 <vm_exec_core+6744>, 0x7facb8d716ab <vm_exec_core+6379>, 0x7facb8d715d3 <vm_exec_core+6163>, 0x7facb8d714d2 <vm_exec_core+5906>, 0x7facb8d72944 <vm_exec_core+11140>, 0x7facb8d71489 <vm_exec_core+5833>, 0x7facb8d71421 <vm_exec_core+5729>, 0x7facb8d713b9 <vm_exec_core+5625>, 0x7facb8d71375 <vm_exec_core+5557>, 0x7facb8d712b1 <vm_exec_core+5361>, 0x7facb8d71226 <vm_exec_core+5222>, 0x7facb8d7330b <vm_exec_core+13643>, 0x7facb8d73321 <vm_exec_core+13665>, 0x7facb8d73337 <vm_exec_core+13687>, 0x7facb8d7334d <vm_exec_core+13709>, 0x7facb8d73363 <vm_exec_core+13731>, 0x7facb8d73379 <vm_exec_core+13753>, 0x7facb8d7338f <vm_exec_core+13775>, 0x7facb8d733ac <vm_exec_core+13804>, 0x7facb8d733c2 <vm_exec_core+13826>, 0x7facb8d733d8 <vm_exec_core+13848>, 0x7facb8d733ee <vm_exec_core+13870>, 0x7facb8d73404 <vm_exec_core+13892>, 0x7facb8d7341a <vm_exec_core+13914>...} #49 0x00007facb8d77039 in rb_vm_exec (ec=0x7fac803c97d0) at vm.c:2586 _ec = 0x7fac803c97d0 _tag = {tag = 36, retval = 4, buf = {0x0, 0x7facb8d77040 <rb_vm_exec+400>, 0x0, 0x7fac71917bb0, 0x0}, prev = 0x7fac71917ca0, state = RUBY_TAG_NONE, lock_rec = 0} state = RUBY_TAG_NONE result = <optimized out> #50 0x00007fac8454d5e2 in ??? () #51 0x00007fac71918080 in ??? () #52 0x00007fac803c97d0 in ??? () #53 0x00007fac71937f58 in ??? () #54 0x00007facb8d76f98 in jit_exec_exception (ec=<optimized out>) at vm.c:509 func = <optimized out> func = <optimized out> #55 vm_exec_loop (result=<optimized out>, tag=<optimized out>, state=<optimized out>, ec=<optimized out>) at vm.c:2612 vm_loop_start = <optimized out> vm_loop_start = <optimized out> #56 rb_vm_exec (ec=0x7fac803c97d0) at vm.c:2589 _ec = 0x7fac803c97d0 _tag = {tag = 36, retval = 4, buf = {0x0, 0x7facb8d77040 <rb_vm_exec+400>, 0x0, 0x7fac71917c80, 0x0}, prev = 0x7fac71917d70, state = RUBY_TAG_NONE, lock_rec = 0} state = RUBY_TAG_NONE result = <optimized out> #57 0x00007fac842cd7b8 in ??? () --Type <RET> for more, q to quit, c to continue without paging-- #58 0x00007fac71918048 in ??? () #59 0x00007fac803c97d0 in ??? () #60 0x00007fac71937f90 in ??? () #61 0x00007facb8d76f98 in jit_exec_exception (ec=<optimized out>) at vm.c:509 func = <optimized out> func = <optimized out> #62 vm_exec_loop (result=<optimized out>, tag=<optimized out>, state=<optimized out>, ec=<optimized out>) at vm.c:2612 vm_loop_start = <optimized out> vm_loop_start = <optimized out> #63 rb_vm_exec (ec=0x7fac803c97d0) at vm.c:2589 _ec = 0x7fac803c97d0 _tag = {tag = 36, retval = 4, buf = {0x0, 0x7facb8d77040 <rb_vm_exec+400>, 0x0, 0x7fac71917d50, 0x7fac9be125b0}, prev = 0x7fac71917e40, state = RUBY_TAG_NONE, lock_rec = 0} state = RUBY_TAG_NONE result = <optimized out> #64 0x00007fac842cd6ce in ??? () #65 0x00007fac803c9780 in ??? () #66 0x0000000000000000 in ??? () ``` -- https://bugs.ruby-lang.org/

4 16

[ruby-core:120841] [Ruby master Bug#21101] Encoding::CompatibilityError when using String#strip
by jpeterburs (Jonas Peterburs) 30 Jan '25

30 Jan '25

Issue #21101 has been reported by jpeterburs (Jonas Peterburs). ---------------------------------------- Bug #21101: Encoding::CompatibilityError when using String#strip https://bugs.ruby-lang.org/issues/21101 * Author: jpeterburs (Jonas Peterburs) * Status: Open * ruby -v: 3.2.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When opening an ISO 8859-1 encoded file containing a German letter (e.g. ö), then parsing through each line and stripping whitespace using either `rstrip` or `strip` it raises an Error ( `lstrip` seams fine; I'd assume it skips stripping when there isn't any whitespace in front of the string). ``` ruby File.open('test.dat').each_line { |line| line.strip } # raises Encoding::CompatibilityError ``` I've tried this with multiple ruby versions. It was working as expected in these versions: - 2.7.8 - 3.0.0 - 3.0.7 - 3.1.0 - 3.1.1 - 3.1.2 - 3.1.3 - 3.1.4 - 3.1.5 - 3.1.6 And it didn't work in these: - 3.2.0 - 3.2.1 - 3.2.2 - 3.2.3 - 3.2.4 - 3.2.5 - 3.2.6 - 3.3.6 - 3.3.7 I didn't find anything in the Patch notes of ruby 3.2.0 about the changed behavior. Did I miss something? ---Files-------------------------------- test.dat (142 Bytes) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120836] [Ruby master Bug#14480] miniruby crashing when compiled with -O2 or -O1 on aarch64
by thesamesam (Sam James) 30 Jan '25

30 Jan '25

Issue #14480 has been updated by thesamesam (Sam James). vo.x (Vit Ondruch) wrote in #note-19: > I don't understand why this change was applied. This should be either enabled everywhere or disabled everywhere, not enabled on some random platforms. Please note that this should not be issue on aarch64 for a while. > > Or was the issue exhibited somewhere recently? The commit does not elaborate about it. We had a report of this in Gentoo today on amd64: https://bugs.gentoo.org/949016. Using setjmp worked. Having read over the discussions with the GCC developers, I don't think `__builtin_setjmp` should ever be used if `setjmp` is available. ---------------------------------------- Bug #14480: miniruby crashing when compiled with -O2 or -O1 on aarch64 https://bugs.ruby-lang.org/issues/14480#change-111700 * Author: vo.x (Vit Ondruch) * Status: Closed * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [aarch64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Recently, it is not possible to build Ruby 2.5.0 on aarch64 on Fedora Rawhide, because miniruby fails during build: ~~~ ... snip ... ./miniruby -I./lib -I. -I.ext/common -n \ -e 'BEGIN{version=ARGV.shift;mis=ARGV.dup}' \ -e 'END{abort "UNICODE version mismatch: #{mis}" unless mis.empty?}' \ -e '(mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +"#{Regexp.quote(version)}"/o' \ 10.0.0 ./enc/unicode/10.0.0/casefold.h ./enc/unicode/10.0.0/name2ctype.h generating encdb.h ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -c -o encdb.h ./template/encdb.h.tmpl ./enc enc generating prelude.c ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -I. -c -o prelude.c \ ./template/prelude.c.tmpl ./prelude.rb ./gem_prelude.rb ./abrt_prelude.rb *** stack smashing detected ***: <unknown> terminated encdb.h updated ... snip ... ~~~ This might by Ruby or gcc issue. Not sure yet. However, there is already lengthy analysis available in Fedora's Bugzilla [1]. Would be anybody able to help to resolve this issue? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1545239 ---Files-------------------------------- Dockerfile (573 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120831] Undeliverable: outgoing messages failure
by Postmaster 29 Jan '25

29 Jan '25

1 0

[ruby-core:117765] [Ruby master Feature#20470] Extract Ruby's Garbage Collector
by peterzhu2118 (Peter Zhu) 29 Jan '25

29 Jan '25

Issue #20470 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #20470: Extract Ruby's Garbage Collector https://bugs.ruby-lang.org/issues/20470 * Author: peterzhu2118 (Peter Zhu) * Status: Open ---------------------------------------- # Extract Ruby's Garbage Collector ## Background As described in [[Feature #20351]](https://bugs.ruby-lang.org/issues/20351), we are working on the ability to plug alternative garbage collector implementations into Ruby. Our goal is to allow developers and researchers to create and experiment with new implementations of garbage collectors in Ruby in a simplified way. This will also allow experimentation with different GC implementations in production systems so users can choose the best GC implementation for their workloads. ## Implementation GitHub PR: [10721](https://github.com/ruby/ruby/pull/10721) In this patch, we have split the current `gc.c` file into two files: `gc.c` and `gc_impl.c`. `gc.c` now only contains code not specific to Ruby GC. This includes code to mark objects (which the GC implementation may choose not to use) and wrappers for internal APIs that the implementation may need to use (e.g. locking the VM). `gc_impl.c` now contains the implementation of Ruby's GC. This includes marking, sweeping, compaction, and statistics. Most importantly, `gc_impl.c` only uses public APIs in Ruby and a limited set of functions exposed in `gc.c`. This allows us to build `gc_impl.c` independently of Ruby and plug Ruby's GC into itself. ## Demonstration After [checking out the branch](https://github.com/ruby/ruby/pull/10721), we can first configure with `--with-shared-gc`: ```bash $ ./configure --with-shared-gc ... $ make -j ... ``` Let's now change the slot size of the GC to 64 bytes: ```bash $ sed -i 's/$#define BASE_SLOT_SIZE$.*/\1 64/' gc_impl.c ``` We can compile `gc_impl.c` independently using the following commands for clang or gcc (you may have to change the last `-I` to match your architecture and platform): ```bash $ clang -Iinclude -I. -I.ext/include/arm64-darwin23 -undefined dynamic_lookup -g -O3 -dynamiclib -o libgc.dylib gc_impl.c $ gcc -Iinclude -I. -I.ext/include/x86_64-linux -Wl,-undefined,dynamic_lookup -fPIC -g -O3 -shared -o libgc.so gc_impl.c ``` We can see that by default, the slot size is 40 bytes and objects are 40 bytes in size: ```bash $ ./ruby -e "puts GC.stat_heap(0, :slot_size)" 40 $ ./ruby -robjspace -e "puts ObjectSpace.dump(Object.new)" {"address":"0x1054a23f0", "type":"OBJECT", "shape_id":3, "slot_size":40, "class":"0x10528fd38", "embedded":true, "ivars":0, "memsize":40, "flags":{"wb_protected":true}} ``` We can now load our new GC using the `RUBY_GC_LIBRARY_PATH` environment variable (note that you may have to change the path to the DSO): ```bash $ RUBY_GC_LIBRARY_PATH=./libgc.dylib ./ruby -e "puts GC.stat_heap(0, :slot_size)" 64 $ RUBY_GC_LIBRARY_PATH=./libgc.dylib ./ruby -robjspace -e "puts ObjectSpace.dump(Object.new)" {"address":"0x1038de440", "type":"OBJECT", "shape_id":3, "slot_size":64, "class":"0x10355fc00", "embedded":true, "ivars":0, "memsize":64, "flags":{"wb_protected":true}} ``` ## Benchmark Benchmarks were ran on commit [c78cebb](https://github.com/ruby/ruby/commit/c78cebb469fe56b45ee5daad16ae97… on Ubuntu 22.04 using [yjit-bench](https://github.com/Shopify/yjit-bench/) on commit [cc5a76e](https://github.com/Shopify/yjit-bench/commit/cc5a76ef6240113650547…. Compiling gc_impl branch without `--with-shared-gc` (i.e. how the default Ruby is built), the benchmarks show little to no decrease in performance, with most of it being 0% to 1% slower: ``` -------------- ----------- ---------- ------------ ---------- --------------- -------------- bench master (ms) stddev (%) gc_impl (ms) stddev (%) gc_impl 1st itr master/gc_impl activerecord 73.9 0.3 74.6 0.3 1.00 0.99 chunky-png 911.1 0.2 937.2 0.2 0.97 0.97 erubi-rails 1582.4 0.1 1583.5 0.0 1.00 1.00 hexapdf 2716.2 1.1 2760.2 0.7 1.00 0.98 liquid-c 68.9 0.5 68.6 0.4 1.00 1.00 liquid-compile 67.9 0.1 68.2 0.2 0.99 1.00 liquid-render 172.8 0.1 174.9 0.1 0.99 0.99 lobsters 1033.9 0.4 1036.0 0.3 1.08 1.00 mail 135.1 0.2 136.5 0.2 0.99 0.99 psych-load 2250.8 0.1 2274.9 0.3 0.99 0.99 railsbench 2499.2 0.2 2502.9 0.1 1.00 1.00 rubocop 178.3 0.5 179.8 0.4 1.00 0.99 ruby-lsp 116.8 0.1 118.5 0.2 1.00 0.99 sequel 75.4 0.2 76.2 0.3 0.99 0.99 -------------- ----------- ---------- ------------ ---------- --------------- -------------- ``` Compiling gc_impl branch with `--with-shared-gc` and loading Ruby's current GC using `RUBY_GC_LIBRARY_PATH`, the benchmarks are still fairly good with performance decrease of only around 1% to 2%: ``` -------------- ----------- ---------- ------------ ---------- --------------- -------------- bench master (ms) stddev (%) gc_impl (ms) stddev (%) gc_impl 1st itr master/gc_impl activerecord 74.2 0.2 75.4 0.5 0.98 0.98 chunky-png 916.3 0.3 933.2 0.1 0.98 0.98 erubi-rails 1597.6 0.1 1586.3 0.2 1.01 1.01 hexapdf 2731.4 0.5 2776.8 0.7 1.00 0.98 liquid-c 68.5 0.1 68.9 0.4 0.97 0.99 liquid-compile 67.4 0.4 68.3 0.2 0.95 0.99 liquid-render 171.8 0.1 175.6 0.2 0.97 0.98 lobsters 1031.9 0.3 1041.4 0.3 0.94 0.99 mail 135.5 0.4 136.7 0.1 0.99 0.99 psych-load 2246.0 0.1 2281.3 0.1 0.99 0.98 railsbench 2490.9 0.0 2490.0 0.1 1.01 1.00 rubocop 179.8 2.3 180.0 0.4 0.94 1.00 ruby-lsp 117.3 0.1 118.5 0.1 0.99 0.99 sequel 75.8 0.5 76.3 0.2 0.99 0.99 -------------- ----------- ---------- ------------ ---------- --------------- -------------- ``` ## Limitations We recognize that our current implementation does not yet offer the flexibility required for a generic plug-in GC. Specifically, the set of APIs that the plug-in GC has to implement is relatively large, at around 70 functions. Additionally, some of these functions are specific to the current GC. We would like to emphasize that the API is NOT stable and is subject to change. We will be working on improving this API and reducing the surface area. This will be future work and we're not working on it in this phase. ## Future plans - Refactor and improve `gc_impl.c`. - Implement alternate GC implementations, such as the Epsilon GC and [MMTk](https://www.mmtk.io/) to prove that this API allows for alternate implementations of the GC. - Reduce and improve the API of the GC implementation. - Benchmark and improve performance of the DSO API. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:120816] Invitation to RubyKaigi 2025
by Akira Matsuda 29 Jan '25

29 Jan '25

To: ruby-core members Let me announce that registration for RubyKaigi 2025 is now open! And of course as usual, all Ruby core team members (who have direct commit access to the Git repo) are invited to the conference with free admission. Please proceed to our ticketing site from this URL: https://ti.to/rubykaigi/2025/with/zdgor1tqzpw For "Committer account name" field, please fill in your account name listed on the committer email list on GH, https://github.com/ruby/ruby-commit-hook/blob/master/config/email.yml or SVN account name, or Redmine account name, or something equivalent that identifies you as a Ruby core committer. See you there in Matz-yama! ♨️ -- Akira Matsuda<ronnie(a)dio.jp>

1 0

[ruby-core:119201] [Ruby master Bug#20743] ruby doesn't properly split RUBY_DEBUG_LOG_FILTER into items
by x-yuri (Yuri Kanivetsky) 28 Jan '25

28 Jan '25

Issue #20743 has been reported by x-yuri (Yuri Kanivetsky). ---------------------------------------- Bug #20743: ruby doesn't properly split RUBY_DEBUG_LOG_FILTER into items https://bugs.ruby-lang.org/issues/20743 * Author: x-yuri (Yuri Kanivetsky) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-15T01:06:11Z master 532af89e3b) +PRISM [x86_64-linux-musl] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` $ docker run --rm alpine:3.20.3 sh -euxc ' apk add git build-base autoconf ruby yaml-dev zlib-dev openssl-dev libffi-dev git clone https://github.com/ruby/ruby cd ruby git checkout 532af89e3b5b78dd3a6fe29c6cc64ad1b073afe2 ./autogen.sh ./configure cflags=-DUSE_RUBY_DEBUG_LOG --disable-install-doc make -j8 install ruby -v RUBY_DEBUG_LOG=stderr RUBY_DEBUG_LOG_FILTER=rb_thread_schedule_limits,rb_ractor_thread_switch ruby -e "" ' ... + RUBY_DEBUG_LOG=stderr RUBY_DEBUG_LOG_FILTER=rb_thread_schedule_limits,rb_ractor_thread_switch ruby -e RUBY_DEBUG_LOG=stderr [stderr] RUBY_DEBUG_LOG_FILTER[0]=rb_thread_schedule_limit (all) RUBY_DEBUG_LOG_FILTER[1]=rb_ractor_thread_switch (all) ... ``` As you can see `ruby` reports that `RUBY_DEBUG_LOG_FILTER[0]` equals `rb_thread_schedule_limit`, not `rb_thread_schedule_limits`. This happens because here: https://github.com/ruby/ruby/blob/532af89e3b5b78dd3a6fe29c6cc64ad1b073afe2/… `1` should not be subtracted. Also in the following lines `str` is increased, but `len` is not decreased. It makes sense to recheck if there are no further mistakes. -- https://bugs.ruby-lang.org/

3 3