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

[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

[ruby-core:120797] [Ruby master Bug#21091] recursive require not detected on case insensitive filesystem
by rrotter (Ryan Rotter) 27 Jan '25

27 Jan '25

Issue #21091 has been reported by rrotter (Ryan Rotter). ---------------------------------------- Bug #21091: recursive require not detected on case insensitive filesystem https://bugs.ruby-lang.org/issues/21091 * Author: rrotter (Ryan Rotter) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On case insensitive filesystems `require`ing a file from itself causes the file to be `require`d twice if the initial `require` and the `require` inside the file have different capitalization. I expect the second `require` to return false, and not execute the file a second time. ``` ~ % cat /tmp/foo.rb puts "loading #{__FILE__}" require "/tmp/foo" SOME_GLOBAL = "foobar".freeze ~ % ruby -r/tmp/FOO loading /tmp/FOO.rb loading /tmp/foo.rb /tmp/FOO.rb:3: warning: already initialized constant SOME_GLOBAL /tmp/foo.rb:3: warning: previous definition of SOME_GLOBAL was here ``` This is on macOS 15.1.1, using the default case-insensitive APFS, and ruby 3.4.1. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118879] [Ruby master Bug#20682] Slave PTY output is lost after a child process exits in macOS
by ono-max (Naoto Ono) 27 Jan '25

27 Jan '25

Issue #20682 has been reported by ono-max (Naoto Ono). ---------------------------------------- Bug #20682: Slave PTY output is lost after a child process exits in macOS https://bugs.ruby-lang.org/issues/20682 * Author: ono-max (Naoto Ono) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- According to Launchable, the following PTY tests are flaky only on macOS. https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… It's because the slave PTY output is lost after a child process exits in macOS. Here is the code to reproduce the problem. When I remove `sleep 3` from the code, "a" is returned. ``` require 'pty' r, w, pid = PTY.spawn('ruby', '-e', 'puts "a"') sleep 3 puts r.gets #=> Returns nil ``` Based on my investigation, this issue happens in the macOS side and it's almost same as https://github.com/pexpect/pexpect/issues/662. The cause is described as follows in the ticket: > // NOTE[macOS-S_CTTYREF]: On macOS, after a forkpty(), if the pty slave (child) // is closed before the pty master (parent) reads, the pty's buffer is cleared // thus the master (parent) reads nothing. This can happen if the child exits // before the parent has a chance to call master.read(). // // This issue has been reported to Apple, but has not been resolved: // https://developer.apple.com/forums/thread/663632 // // Work around this issue by opening /dev/tty then closing it. This ultimately // causes the child's exit() to flush the slave pty's output buffer in a // blocking way. This fixes the problem on macOS 13.2 in my testing. // // Here's how the workaround works in detail: // // If we open /dev/tty, it sets the S_CTTYREF flag on the process. This flag // remains set if we close the /dev/tty file descriptor. // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // Additionally, opening /dev/tty retains a reference to the pty slave. // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // // When the child process exits: // // 1. All open file descriptors (including stdin/stdout/stderr which are the pty // slave) are closed. This does *not* drain unread pty slave output. // * If S_CTTYREF was set, closing the file descriptors does not close the // last reference to the pty slave, so no cleanup happens yet. // * NOTE[macOS-pty-close-loss]: If S_CTTYREF was not set, closing the file // descriptors drops the last reference to the pty slave. Unread data is // dropped. // // 2. If the S_CTTYREF flag is set on the child process, the controlling // terminal (pty slave) is closed. XNU's ptsclose() ultimately calls // ttywait(). // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // * ttywait() is the same as ioctl(slave, TIOCDRAIN); it blocks waiting for // output to be received. // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // * NOTE[macOS-pty-waitpid-hang]: Because of the blocking ttywait(), the // process is in an exiting (but not zombie) state. waitpid() will hang. // // * NOTE[macOS-pty-close-loss]: If the S_CTTYREF flag is not set on the // child process, ttywait() is not called, thus the pty slave does not // block waiting for the output to be received, and the output is dropped. // A well-behaving parent will use a poll() loop anyway, so this isn't a // problem. (It does make quick tests annoying to write though.) // // Demonstration of NOTE[macOS-pty-close-loss] (S_CTTYREF is not set before // exit): // // // On macOS, this program should report 'data = ""', demonstrating that // // writes are lost. // // #include <stdlib.h> // #include <errno.h> // #include <stdio.h> // #include <string.h> // #include <unistd.h> // #include <util.h> // // int main() { // int tty_fd; // pid_t pid = forkpty(&tty_fd, /*name=*/NULL, /*termp=*/NULL, // /*winp=*/NULL); // if (pid == -1) { perror("forkpty"); abort(); } // // if (pid == 0) { // // Child. // (void)write(STDOUT_FILENO, "y", 1); // exit(0); // } else { // // Parent. // // // Cause the child to write() then exit(). exit() will drop written // // data. // sleep(1); // // char buffer[10]; // ssize_t rc = read(tty_fd, buffer, sizeof(buffer)); // if (rc < 0) { perror("read"); abort(); } // fprintf(stderr, "data = \"%.*s\"\n", (int)rc, buffer); // } // // return 0; // } // // Demonstration of NOTE[macOS-pty-waitpid-hang] (S_CTTYREF is set before exit): // // // On macOS, this program should hang, demonstrating that the child // // process doesn't finish exiting. // // // // During the hang, observe that the child is in an exiting state ("E"): // // // // $ ps -e -o pid,stat | grep 20125 // // 20125 ?Es // // #include <errno.h> // #include <fcntl.h> // #include <stdio.h> // #include <stdlib.h> // #include <string.h> // #include <unistd.h> // #include <util.h> // // int main() { // int tty_fd; // pid_t pid = forkpty(&tty_fd, /*name=*/NULL, /*termp=*/NULL, // /*winp=*/NULL); // if (pid == -1) { perror("forkpty"); abort(); } // // if (pid == 0) { // // Child. // close(open("/dev/tty", O_WRONLY)); // (void)write(STDOUT_FILENO, "y", 1); // exit(0); // } else { // // Parent. // // fprintf(stderr, "child PID: %d\n", pid); // // // This will hang because, despite the child being is an exiting // // state, the child is waiting for us to read(). // pid_t rc = waitpid(pid, NULL, 0); // if (rc < 0) { perror("waitpid"); abort(); } // } // // return 0; // } In Ruby, PTY is implemented with [fork()](https://github.com/ruby/ruby/blob/master/process.c#L1706) and [posix_openpt()](https://github.com/ruby/ruby/blob/master/ext/pty/pty.c#L329) in macOS. I could reproduce the problem in the following script. ``` #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/ioctl.h> int main() { int master_fd, slave_fd; pid_t child_pid; char *slave_name; // Open a master pseudo-terminal master_fd = posix_openpt(O_RDWR | O_NOCTTY); if (master_fd == -1) { perror("posix_openpt"); exit(1); } // Grant access to the slave pseudo-terminal if (grantpt(master_fd) == -1) { perror("grantpt"); exit(1); } // Unlock the slave pseudo-terminal if (unlockpt(master_fd) == -1) { perror("unlockpt"); exit(1); } // Get the name of the slave pseudo-terminal slave_name = ptsname(master_fd); if (slave_name == NULL) { perror("ptsname"); exit(1); } // Fork a child process child_pid = fork(); if (child_pid == -1) { perror("fork"); exit(1); } else if (child_pid == 0) { // Child process // Open the slave pseudo-terminal slave_fd = open(slave_name, O_RDWR); if (slave_fd == -1) { perror("open"); exit(1); } // Create a new session and process group if (setsid() == -1) { perror("setsid"); exit(1); } // Set the controlling terminal for the child process if (ioctl(slave_fd, TIOCSCTTY, NULL) == -1) { perror("ioctl"); exit(1); } // Duplicate the slave file descriptor to stdin, stdout, and stderr if (dup2(slave_fd, STDIN_FILENO) == -1) { perror("dup2"); exit(1); } if (dup2(slave_fd, STDOUT_FILENO) == -1) { perror("dup2"); exit(1); } if (dup2(slave_fd, STDERR_FILENO) == -1) { perror("dup2"); exit(1); } // close(open("/dev/tty", O_WRONLY)); // Close the original slave file descriptor close(slave_fd); // Execute a shell or other program (void)write(STDOUT_FILENO, "y", 1); exit(1); } else { sleep(5); char buffer[10]; ssize_t rc = read(master_fd, buffer, sizeof(buffer)); if (rc < 0) { perror("read"); abort(); } fprintf(stderr, "data = \"%.*s\"\n", (int)rc, buffer); // Clean up close(master_fd); } return 0; } ``` -- https://bugs.ruby-lang.org/

3 8