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

[ruby-core:114515] [Ruby master Bug#17826] Ractor#take hangs if used in multiple Threads
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17826 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed This appears fixed in Ruby 3.3.0-preview1, though it doesn't work in Ruby 3.2.2. ---------------------------------------- Bug #17826: Ractor#take hangs if used in multiple Threads https://bugs.ruby-lang.org/issues/17826#change-104310 * Author: kukunin (Sergiy Kukunin) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Hello there. I was playing with Ractors (the awesome technology and the big leap for Ruby) and encountered weird behavior. I tried to schedule and run Ractors in multiple threads, and found out, that Ractor#take hangs even if the ractor is finished. Here is code to reproduce: ``` ruby Array.new(2) do |n| Thread.new do r = Ractor.new do sleep 0.001 end r.take puts "thread #{n} finished" end end.each(&:join) puts 'done' ``` The output is just "thread 0 finished" and the process hangs forever. Sometimes the second thread exists first, and the first freezes. Thank you for your time. Hopefully, it's a valid bug report, not me just misusing the feature =) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114514] [Ruby master Bug#17799] Seg fault in rb_class_clear_method_cache
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17799 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Feedback @stanhu Have you had any similar failures with Ruby 3.2? ---------------------------------------- Bug #17799: Seg fault in rb_class_clear_method_cache https://bugs.ruby-lang.org/issues/17799#change-104309 * Author: stanhu (Stan Hu) * Status: Feedback * Priority: Normal * ruby -v: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Recently our CI tests have been intermittently failing with segmentation faults at random points, such as: ``` /builds/gitlab-org/security/gitlab/spec/support/shared_examples/requests/api/issues/merge_requests_count_shared_examples.rb:3: [BUG] Segmentation fault at 0x0000000000000000 ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0042 p:0003 s:0237 e:000236 TOP /builds/gitlab-org/security/gitlab/spec/support/shared_examples/requests/api/issues/merge_requests_count_shared_examples.rb:3 [FINISH] c:0041 p:---- s:0234 e:000233 CFUNC :require c:0040 p:0012 s:0229 e:000228 BLOCK /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.r c:0039 p:0070 s:0226 e:000225 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/loaded_features_index.rb: c:0038 p:0025 s:0214 e:000213 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.r c:0037 p:0055 s:0208 e:000207 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.r c:0036 p:0006 s:0201 e:000200 BLOCK /builds/gitlab-org/security/gitlab/spec/spec_helper.rb:71 [FINISH] c:0035 p:---- s:0197 e:000196 CFUNC :each c:0034 p:0563 s:0193 e:000192 TOP /builds/gitlab-org/security/gitlab/spec/spec_helper.rb:71 [FINISH] c:0033 p:---- s:0187 e:000186 CFUNC :require c:0032 p:0007 s:0182 e:000181 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:2112 c:0031 p:0008 s:0173 e:000172 BLOCK /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:1574 [FINISH] c:0030 p:---- s:0169 e:000168 CFUNC :each c:0029 p:0042 s:0165 e:000164 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:1574 c:0028 p:0048 s:0159 e:000158 BLOCK /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration_options.rb:113 [FINISH] c:0027 p:---- s:0155 e:000154 CFUNC :each c:0026 p:0019 s:0151 e:000150 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration_options.rb:112 c:0025 p:0005 s:0145 e:000144 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration_options.rb:22 c:0024 p:0035 s:0140 e:000139 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:132 c:0023 p:0007 s:0134 e:000133 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:99 c:0022 p:0007 s:0128 e:000127 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:86 c:0021 p:0065 s:0122 e:000121 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:71 c:0020 p:0020 s:0114 e:000113 METHOD /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:45 c:0019 p:0025 s:0109 e:000108 TOP /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/exe/rspec:4 [FINISH] c:0018 p:---- s:0106 e:000105 CFUNC :load c:0017 p:0112 s:0101 e:000100 TOP /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/bin/rspec:23 [FINISH] c:0016 p:---- s:0096 e:000095 CFUNC :load c:0015 p:0107 s:0091 e:000090 METHOD /usr/local/lib/ruby/2.7.0/bundler/cli/exec.rb:63 c:0014 p:0071 s:0083 e:000082 METHOD /usr/local/lib/ruby/2.7.0/bundler/cli/exec.rb:28 c:0013 p:0024 s:0078 e:000077 METHOD /usr/local/lib/ruby/2.7.0/bundler/cli.rb:476 c:0012 p:0054 s:0073 e:000072 METHOD /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor/command.rb:27 c:0011 p:0040 s:0065 e:000064 METHOD /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor/invocation.rb:127 c:0010 p:0239 s:0058 e:000057 METHOD /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor.rb:399 c:0009 p:0008 s:0045 e:000044 METHOD /usr/local/lib/ruby/2.7.0/bundler/cli.rb:30 c:0008 p:0066 s:0040 e:000039 METHOD /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor/base.rb:476 c:0007 p:0008 s:0033 e:000032 METHOD /usr/local/lib/ruby/2.7.0/bundler/cli.rb:24 c:0006 p:0109 s:0028 e:000027 BLOCK /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/libexec/bundle:46 c:0005 p:0002 s:0022 e:000021 METHOD /usr/local/lib/ruby/2.7.0/bundler/friendly_errors.rb:123 c:0004 p:0111 s:0017 E:001838 TOP /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/libexec/bundle:34 [FINISH] c:0003 p:---- s:0013 e:000012 CFUNC :load c:0002 p:0112 s:0008 E:002100 EVAL /usr/local/bin/bundle:23 [FINISH] c:0001 p:0000 s:0003 E:001040 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- /usr/local/bin/bundle:23:in `<main>' /usr/local/bin/bundle:23:in `load' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/libexec/bundle:34:in `<top (required)>' /usr/local/lib/ruby/2.7.0/bundler/friendly_errors.rb:123:in `with_friendly_errors' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/libexec/bundle:46:in `block in <top (required)>' /usr/local/lib/ruby/2.7.0/bundler/cli.rb:24:in `start' /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor/base.rb:476:in `start' /usr/local/lib/ruby/2.7.0/bundler/cli.rb:30:in `dispatch' /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor.rb:399:in `dispatch' /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' /usr/local/lib/ruby/2.7.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /usr/local/lib/ruby/2.7.0/bundler/cli.rb:476:in `exec' /usr/local/lib/ruby/2.7.0/bundler/cli/exec.rb:28:in `run' /usr/local/lib/ruby/2.7.0/bundler/cli/exec.rb:63:in `kernel_load' /usr/local/lib/ruby/2.7.0/bundler/cli/exec.rb:63:in `load' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/bin/rspec:23:in `<top (required)>' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/bin/rspec:23:in `load' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/exe/rspec:4:in `<top (required)>' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:45:in `invoke' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:71:in `run' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:86:in `run' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:99:in `setup' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:132:in `configure' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration_options.rb:22:in `configure' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration_options.rb:112:in `process_options_into' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration_options.rb:112:in `each' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration_options.rb:113:in `block in process_options_into' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:1574:in `requires=' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:1574:in `each' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:1574:in `block in requires=' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:2112:in `load_file_handling_errors' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/rspec-core-3.10.1/lib/rspec/core/configuration.rb:2112:in `require' /builds/gitlab-org/security/gitlab/spec/spec_helper.rb:71:in `<top (required)>' /builds/gitlab-org/security/gitlab/spec/spec_helper.rb:71:in `each' /builds/gitlab-org/security/gitlab/spec/spec_helper.rb:71:in `block in <top (required)>' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi' /builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require' /builds/gitlab-org/security/gitlab/spec/support/shared_examples/requests/api/issues/merge_requests_count_shared_examples.rb:3:in `<top (required)>' -- Machine register context ------------------------------------------------ RIP: 0x00007fba9179f8fb RBP: 0x00007ffdb2bc4dc0 RSP: 0x00007ffdb2bc3d40 RAX: 0x0000565411171e60 RBX: 0x0000000000000000 RCX: 0x0000000004bf1491 RDX: 0x00007ffdb2bc4dc0 RDI: 0x00005654110bc550 RSI: 0x00007fba9179f8c0 R8: 0x0000565406728098 R9: 0x00007fba91124170 R10: 0x0000565406726010 R11: 0x00007fba91124170 R12: 0x00007fba9179f8c0 R13: 0x0000000004bd5abc R14: 0x000056543d860c70 R15: 0x0000565435cff1e0 EFL: 0x0000000000010246 -- Other runtime information ----------------------------------------------- ``` We managed to generate a core file from this seg fault: ``` $ docker run -v /tmp/bugs:/bugs -it registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.7.2.patched-golan… bash root@25a81975afab:/bugs# mkdir -p /builds/gitlab-org/security/gitlab/ root@25a81975afab:/bugs# cd /builds/gitlab-org/security/gitlab/ root@25a81975afab:/builds/gitlab-org/security/gitlab# unzip /bugs/cache.zip Archive: /bugs/cache.zip creating: vendor/gitaly-ruby/ creating: vendor/gitaly-ruby/ruby/ creating: vendor/gitaly-ruby/ruby/2.7.0/ creating: vendor/gitaly-ruby/ruby/2.7.0/bin/ inflating: vendor/gitaly-ruby/ruby/2.7.0/bin/codera <snip> root@25a81975afab:/bugs# gdb /usr/local/bin/ruby --core core.bundle.1618331218.363 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/bin/ruby...done. warning: core file may not match specified executable file. [New LWP 363] [New LWP 533] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/builds/gitlab-org/security/gitlab/vendor/ruby/2.7.0/bin/rspec -Ispec -rspec_he'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. [Current thread is 1 (Thread 0x7fba90f65740 (LWP 363))] (gdb) t a a bt Thread 2 (Thread 0x7fba87c62700 (LWP 533)): #0 0x00007fba91056916 in __GI_ppoll (fds=fds@entry=0x7fba87b616d8, nfds=nfds@entry=1, timeout=<optimized out>, timeout@entry=0x7fba87b616e0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39 #1 0x00007fba91771890 in rb_sigwait_sleep (th=th@entry=0x5654120da230, sigwait_fd=sigwait_fd@entry=3, rel=rel@entry=0x7fba87b61790) at hrtime.h:148 #2 0x00007fba91772599 in native_sleep (th=0x5654120da230, rel=0x7fba87b61790) at thread_pthread.c:2099 #3 0x00007fba91775e2f in sleep_hrtime (fl=2, rel=<optimized out>, th=0x5654120da230) at thread.c:1303 #4 rb_thread_wait_for (time=...) at thread.c:1351 #5 0x00007fba916e10e0 in rb_f_sleep (argc=1, argv=0x7fba87b61d58, _=<optimized out>) at process.c:4886 #6 0x00007fba917a4c39 in vm_call_cfunc_with_frame (empty_kw_splat=<optimized out>, cd=0x56540b8b7a80, calling=<optimized out>, reg_cfp=0x7fba87c61ca0, ec=0x5654120da410) at vm_insnhelper.c:2514 #7 vm_call_cfunc (ec=0x5654120da410, reg_cfp=0x7fba87c61ca0, calling=<optimized out>, cd=0x56540b8b7a80) at vm_insnhelper.c:2539 #8 0x00007fba917bd6bc in vm_call_method_each_type (ec=0x5654120da410, cfp=0x7fba87c61ca0, calling=0x7fba87b61a00, cd=0x56540b8b7a80) at vm_insnhelper.c:2925 #9 0x00007fba917bde55 in vm_call_method_each_type (cd=<optimized out>, calling=<optimized out>, cfp=<optimized out>, ec=<optimized out>) at vm_insnhelper.c:3026 #10 vm_call_method (ec=0x5654120da410, cfp=0x7fba87c61ca0, calling=<optimized out>, cd=<optimized out>) at vm_insnhelper.c:3053 #11 0x00007fba917b0072 in vm_sendish (block_handler=<optimized out>, method_explorer=<optimized out>, cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at vm_insnhelper.c:4023 #12 vm_exec_core (ec=0x7fba87b616d8, initial=1) at insns.def:801 #13 0x00007fba917b5b8c in rb_vm_exec (ec=0x5654120da410, mjit_enable_p=1) at vm.c:1920 #14 0x00007fba917b729c in invoke_iseq_block_from_c (me=0x0, is_lambda=<optimized out>, cref=0x0, passed_block_handler=0, kw_splat=<optimized out>, argv=<optimized out>, argc=1, self=94918931276240, captured=<optimized out>, ec=0x5654120da410) at vm.c:1116 #15 invoke_block_from_c_proc (me=0x0, is_lambda=<optimized out>, passed_block_handler=0, kw_splat=<optimized out>, argv=<optimized out>, argc=1, self=94918931276240, proc=0x5654120da410, ec=0x5654120da410) at vm.c:1216 #16 vm_invoke_proc (passed_block_handler=0, kw_splat=<optimized out>, argv=<optimized out>, argc=1, self=94918931276240, proc=0x5654120da410, ec=0x5654120da410) at vm.c:1238 #17 rb_vm_invoke_proc (ec=0x5654120da410, proc=proc@entry=0x5654135f2920, argc=1, argv=<optimized out>, kw_splat=<optimized out>, passed_block_handler=passed_block_handler@entry=0) at vm.c:1259 #18 0x00007fba9177447d in thread_do_start (th=0x5654120da230) at thread.c:697 #19 0x00007fba917764ff in thread_start_func_2 (th=0x5654120da230, stack_start=<optimized out>) at thread.c:745 #20 0x00007fba91776a44 in thread_start_func_1 (th_ptr=<optimized out>) at thread_pthread.c:969 #21 0x00007fba912fefa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #22 0x00007fba910614cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7fba90f65740 (LWP 363)): #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007fba90f8a535 in __GI_abort () at abort.c:79 #2 0x00007fba9157275b in die () at error.c:664 #3 rb_bug_for_fatal_signal (default_sighandler=0x0, sig=sig@entry=11, ctx=ctx@entry=0x565406831a00, fmt=fmt@entry=0x7fba91808f8b "Segmentation fault at %p") at error.c:664 #4 0x00007fba917314db in sigsegv (sig=11, info=0x565406831b30, ctx=0x565406831a00) at signal.c:946 #5 <signal handler called> #6 rb_class_clear_method_cache (klass=0, arg=140439281334464) at vm.c:362 #7 0x00007fba9159b33d in rb_class_foreach_subclass (arg=8, f=<optimized out>, klass=<optimized out>) at class.c:122 #8 rb_class_detach_module_subclasses (klass=<optimized out>) at class.c:147 #9 0x0000000000000000 in ?? () (gdb) ``` This seg fault seems to have occurred `rb_class_clear_method_cache`, perhaps in https://github.com/ruby/ruby/blob/5445e0435260b449decf2ac16f9d09bae3cafe72/… ---Files-------------------------------- job.log (1.93 MB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114513] [Ruby master Feature#17678] Ractors do not restart after fork
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17678 has been updated by jeremyevans0 (Jeremy Evans). Tracker changed from Bug to Feature ruby -v deleted (ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]) Backport deleted (2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN) As Ractors always use separate OS threads, and fork only runs the current thread in the forked process, I don't see a way for Ractors to continue where they left off after fork. I think auto-starting would likely be a bad idea, because auto-starting would not return them to the state they were at fork. The addition of `Ractor#alive?` and/or `Ractor#status` makes sense to me. Even in non-forked processes such methods could be useful. Note that you can get what you want already, by calling `Ractor#inspect`, so these methods would only need to expose information that Ractor is already storing. ---------------------------------------- Feature #17678: Ractors do not restart after fork https://bugs.ruby-lang.org/issues/17678#change-104304 * Author: ivoanjo (Ivo Anjo) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Hello there! I'm working at Datadog on the `ddtrace` gem -- <https://github.com/DataDog/dd-trace-rb> and we're experimenting with using Ractors in our library but run into a few issues. ### Background When running a Ractor as a background process, the Ractor stops & does not restart when the application forks. ### How to reproduce (Ruby version & script) `ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]` ```ruby r2 = Ractor.new do loop { puts "[#{Process.pid}] Ractor"; sleep(1) } end sleep(1) puts "[#{Process.pid}] Forking..." fork do sleep(5) puts "[#{Process.pid}] End fork." end loop do sleep(1) end ``` ### Expectation and result The application prints “Ractor” each second in the main process, but not in the fork. Expected the Ractor (defined as `r2`) to run in the fork. ``` [29] Ractor [29] Ractor [29] Forking... [29] Ractor [29] Ractor [29] Ractor [29] Ractor [29] Ractor [32] End fork. [29] Ractor [29] Ractor [29] Ractor ``` ### Additional notes Threads do not restart across forks either, so it might not be unreasonable to expect consistent behavior. However, it’s possible to detect a dead Thread and recreate it after a fork (e.g. with `#alive?`, `#status`), but there’s no such mechanism for Ractors. ### Suggested solutions 1. Auto-restart Ractors after fork 2. Add additional methods to Ractors that allow users to check & manage the status of the Ractor, similar to Thread. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114512] [Ruby master Bug#17676] Accessing ENV from Ractor raises IsolationError
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17676 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed This was fixed in commit:3aab870761ff0138ffd29e0a08b6cdf151e2acb4 ---------------------------------------- Bug #17676: Accessing ENV from Ractor raises IsolationError https://bugs.ruby-lang.org/issues/17676#change-104303 * Author: delner (David Elner) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Background Accessing ENV variables from a Ractor will raise Ractor::IsolationError, as the Hash is non-shareable. ## How to reproduce ``` ruby ractor = Ractor.new do ENV['PATH'] end ractor.take ``` ## Expectation and result Ractor raises Ractor::IsolationError for ENV Expect to be able to access ENV variables from Ractors without raising an error. ``` `block in <main>': can not access non-shareable objects in constant Object::ENV by non-main Ractor. (Ractor::IsolationError) ``` ## Additional Notes Attempting to create a shareable copy of ENV currently fails: ```ruby Ractor.make_shareable(ENV, copy: true) # TypeError: cannot freeze ENV # from <internal:ractor>:812:in `freeze' ``` ## Suggested solutions 1. If ENV is a mutable hash, make a Ractor-compatible copy of ENV isolated to that Ractor. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114511] [Ruby master Bug#17667] Module#name needs synchronization
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17667 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This appears to have been fixed between Ruby 3.1 and 3.2. Ruby 3.0 and 3.1 both instantly crash with the given example, whereas Ruby 3.2 does not crash even if given a minute. ---------------------------------------- Bug #17667: Module#name needs synchronization https://bugs.ruby-lang.org/issues/17667#change-104302 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0dev (2021-02-28T11:24:42Z master 80e2c45f55) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ```ruby class C; @iv = 1; end Ractor.new{ loop{C.name} } class C 0.step{|i| instance_variable_set("@iv#{i}", i)} end ``` ``` /home/ko1/ruby/src/trunk/test.rb:4: [BUG] Segmentation fault at 0x000056513df4ef10 ruby 3.1.0dev (2021-02-28T11:24:42Z master 80e2c45f55) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:---- s:0017 e:000016 CFUNC :name c:0004 p:0011 s:0013 e:000012 BLOCK /home/ko1/ruby/src/trunk/test.rb:4 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :loop c:0002 p:0004 s:0006 e:000005 BLOCK /home/ko1/ruby/src/trunk/test.rb:4 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/ko1/ruby/src/trunk/test.rb:4:in `block in <main>' /home/ko1/ruby/src/trunk/test.rb:4:in `loop' /home/ko1/ruby/src/trunk/test.rb:4:in `block (2 levels) in <main>' /home/ko1/ruby/src/trunk/test.rb:4:in `name' -- Machine register context ------------------------------------------------ RIP: 0x000056513dbe09dc RBP: 0x000000000000000e RSP: 0x00007f96276e2140 RAX: 0x000056513df4ef10 RBX: 0x0000000000001238 RCX: 0x000000000000000d RDX: 0x0000000000000ee1 RDI: 0x000056513de6f040 RSI: 0x0000000000000001 R8: 0x000056513deedb00 R9: 0x000056513dec70c0 R10: 0x0000000000000000 R11: 0x00007f96276e2d29 R12: 0x00000000000040d8 R13: 0x000056513dea2470 R14: 0x00000000000076d5 R15: 0xffffffffffffffff EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /home/ko1/ruby/build/trunk/miniruby(rb_print_backtrace+0x11) [0x56513dc7e67e] /home/ko1/ruby/src/trunk/vm_dump.c:758 /home/ko1/ruby/build/trunk/miniruby(rb_vm_bugreport) /home/ko1/ruby/src/trunk/vm_dump.c:1042 /home/ko1/ruby/build/trunk/miniruby(rb_bug_for_fatal_signal+0xf4) [0x56513da892e4] /home/ko1/ruby/src/trunk/error.c:801 /home/ko1/ruby/build/trunk/miniruby(sigsegv+0x4d) [0x56513dbd5cbd] /home/ko1/ruby/src/trunk/signal.c:960 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f962b7283c0] ../sysdeps/pthread/funlockfile.c:28 /home/ko1/ruby/build/trunk/miniruby(find_table_entry_ind+0x5c) [0x56513dbe09dc] /home/ko1/ruby/src/trunk/st.c:839 /home/ko1/ruby/build/trunk/miniruby(rb_st_lookup+0x4a) [0x56513dbe16fa] /home/ko1/ruby/src/trunk/st.c:1021 /home/ko1/ruby/build/trunk/miniruby(classname+0x79) [0x56513dc46380] /home/ko1/ruby/src/trunk/variable.c:102 /home/ko1/ruby/build/trunk/miniruby(rb_mod_name+0x32) [0x56513dc46405] /home/ko1/ruby/src/trunk/variable.c:121 /home/ko1/ruby/build/trunk/miniruby(vm_call_cfunc_with_frame+0x11b) [0x56513dc562eb] /home/ko1/ruby/src/trunk/vm_insnhelper.c:2924 /home/ko1/ruby/build/trunk/miniruby(vm_sendish+0xe) [0x56513dc63957] /home/ko1/ruby/src/trunk/vm_insnhelper.c:4525 ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114510] [Ruby master Bug#17543] Ractor isolation broken by `self` in shareable proc
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17543 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This was fixed in commit:cce331272b07636d536c8227288ab3fbcf24e2aa ---------------------------------------- Bug #17543: Ractor isolation broken by `self` in shareable proc https://bugs.ruby-lang.org/issues/17543#change-104301 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: 3.0.0p0 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Discussing with @MaxLap we realized that the `self` in a shareable proc is not properly isolated: ``` class Foo attr_accessor :x def pr Ractor.make_shareable(Proc.new { self }) end end f = Foo.new f.x = [1, 2, 3] Ractor.new(f.pr) { |pr| pr.call.x << :oops } p f.x # => [1, 2, 3, :oops] ``` If the `self` refers to a shareable object then it's fine, but for non-shareable objects it has to be reset to `nil` or to a global shareable object that would have an instructive `inspect`. ```ruby Ractor::DETACHED_SELF = Object.new def << Ractor::DETACHED_SELF def inspect '<#detached self>' end alias to_s inspect end Ractor::DETACHED_SELF.freeze ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114509] [Ruby master Bug#17531] `did_you_mean` not Ractor friendly
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17531 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This was fixed, did_you_mean is now Ractor-friendly: https://github.com/ruby/did_you_mean/commit/8faba54b2d3ec9aa570691775f14380… ---------------------------------------- Bug #17531: `did_you_mean` not Ractor friendly https://bugs.ruby-lang.org/issues/17531#change-104300 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: 3.0.0p0 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The gem `did_you_mean` uses a class instance variable that does not work with Ractor. ``` $ RUBYOPT='--disable-did_you_mean' ruby -W0 -e 'Ractor.new{ begin ; nil + 42; rescue Exception => e; e.to_s end}.take' # => prints nothing (ok) $ ruby -W0 -e 'Ractor.new{ begin ; nil + 42; rescue Exception => e; e.to_s end}.take' # Prints /Users/mal/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean.rb:102:in `formatter' /Users/mal/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/core_ext/name_error.rb:9:in `to_s' -e:1:in `rescue in block in <main>' -e:1:in `block in <main>' # (not ok) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114508] [Ruby master Bug#17478] Ruby3.0 is slower than Ruby2.7.2 when parsing a large CSV file
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17478 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed I did some testing with the CSV example given in the original post repeated 400k times. Note that Ruby 2.7 ships with CSV 3.1.2 and Ruby 3.2 ships with CSV 3.2.6. * 2.7: 49 seconds * 3.2: 77 seconds * 3.2 --yjit: 59 seconds * 3.2 with CSV 3.1.2: 48 seconds * 3.2 --yjit with CSV 3.1.2: 33 seconds Since the performance issue is in the `csv` library, and not in Ruby itself, I'm closing this. You may want to bisect changes to the `csv` library between 3.1.2 and 3.2.6, and if you identify an unnecessary performance regression, file an issue upstream: https://github.com/ruby/csv/issues . Alternatively, just use CSV 3.1.2 if performance is an issue and you don't need features added since. ---------------------------------------- Bug #17478: Ruby3.0 is slower than Ruby2.7.2 when parsing a large CSV file https://bugs.ruby-lang.org/issues/17478#change-104297 * Author: okkez (okkez _) * Status: Closed * Priority: Normal * Assignee: kou (Kouhei Sutou) * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Ruby3.0 is around 10%-20% slower than Ruby2.7.2 when parsing and aggregating a large CSV file. The script is here: ```ruby require "csv" name_to_cost = Hash.new(0) CSV.foreach(ARGV[0], headers: true) do |row| name_to_cost[row["name"]] += row["cost"].to_f end name_to_cost.sort_by {|k, _| k }.each do |name, cost| printf "%s\t%.3f\n", name, cost end ``` The sample data is like following(3 mega lines and the size is about 235MiB): ``` id,name,description,cost 2365599605,ysgHDPA,Voluptatem sit perferendis accusantium consequatur aut.,25.115 2365599606,xFLXOtJ,Sit accusantium aut perferendis voluptatem consequatur.,60.228 2365599607,RlkxNQB,Accusantium sit aut consequatur perferendis voluptatem.,79.663 2365599608,YVMbuva,Sit perferendis voluptatem accusantium aut consequatur.,49.863 2365599609,rtxVcDW,Accusantium voluptatem sit perferendis aut consequatur.,50.765 2365599610,rtxVcDW,Aut sit accusantium consequatur perferendis voluptatem.,94.310 2365599611,muDwuke,Consequatur sit accusantium aut perferendis voluptatem.,16.991 2365599612,tkqFWyM,Perferendis sit voluptatem consequatur aut accusantium.,98.753 ``` * Ruby2.7.2: 25.37 seconds * Ruby3.0.0: 27.53 seconds I use this program to generate the test CSV file: https://gist.github.com/okkez/05ffa0df08cf49014f460eb2e8543698 In case of using another private data: * Ruby2.7.2: 31.54 seconds * Ruby3.0.0: 37.15 seconds The private data is like followings: * There are 18 columns * There are 1144305 lines * It is 334MiB -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114505] [Ruby master Bug#17383] 3.0 recursion memory|speed issues
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #17383 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed I tested the example: * 2.7: 1178 seconds * 3.2: 1315 seconds * 3.2 --yjit: 1012 seconds 3.2 with --yjit is ~15% faster than 2.7, so whatever performance has been lost since 2.7 has been more than regained by --yjit. ---------------------------------------- Bug #17383: 3.0 recursion memory|speed issues https://bugs.ruby-lang.org/issues/17383#change-104294 * Author: jzakiya (Jabari Zakiya) * Status: Closed * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Testing 3.0.0-preview2 against 2.7.2 I see it's still not as performant to 2.7.2 for the following code. Below is code from Rosettacode.org https://rosettacode.org/wiki/Palindromic_gapful_numbers#Orders_of_Magnitude… This is run on an I7, 3.5GHz, 16GB, Linux 5.9.10 laptop. Using rvm, 2.7.2 uses at max ~50% of memory worst case, but for 3.0.0pre2 it hits ~70%. It's also faster on 2.7.2 than 3.0.0-pre2 ``` class PalNo def initialize(digit) @digit, @l, @dd = digit, 3, 11*digit end def fN(n) return [0,1,2,3,4,5,6,7,8,9] if n==1 return [0,11,22,33,44,55,66,77,88,99] if n==2 a=[]; [0,1,2,3,4,5,6,7,8,9].product(fN(n-2)).each{ |g| a << g[0]*10**(n-1)+g[0]+10*g[1] }; return a end def show(count, keep) to_skip, palcnt, pals = count - keep, 0, [] while palcnt < count fN((a)l-2).each{ |g| pal=@digit*10**(@l-1)+@digit+10*g; pals << pal if pal%(@dd)==0 && (palcnt += 1) > to_skip; break if palcnt - to_skip == keep }; @l+=1 end print pals; puts end end start = Time.now (1..9).each { |digit| PalNo.new(digit).show(20, 20) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(100, 15) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(1000, 10) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(100_000, 1) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(1_000_000, 1) }; puts "####" (1..9).each { |digit| PalNo.new(digit).show(10_000_000, 1) }; puts "####" puts (Time.now - start) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114495] [Ruby master Bug#19848] Ripper BOM behavior
by kddnewton (Kevin Newton) 24 Aug '23

24 Aug '23

Issue #19848 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #19848: Ripper BOM behavior https://bugs.ruby-lang.org/issues/19848 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When there is a byte-order mark in a file, the first token in the file usually begins at -3. For example: ```ruby Ripper.lex("\xEF\xBB\xBF[]") # => [[[1, -3], :on_lbracket, "[", BEG|LABEL], [[1, 1], :on_rbracket, "]", END]] ``` The rest of the tokens appear as if the byte-order-mark never existed. This is consistent except for the case where the file starts with a global variable, an instance variable, or a class variable. In those cases the first token begins at 0. For example: ```ruby Ripper.lex("\xEF\xBB\xBF@foo") # => [[[1, 0], :on_ivar, "@foo", END]] Ripper.lex("\xEF\xBB\xBF@@foo") # => [[[1, 0], :on_cvar, "@@foo", END]] Ripper.lex("\xEF\xBB\xBF$foo") # => [[[1, 0], :on_gvar, "$foo", END]] ``` Additionally, when there is a byte-order mark it usually does not appear as part of the first token, unless the token is a magic encoding comment. If it's a magic encoding comment, then it's part of the value: ```ruby Ripper.lex("\xEF\xBB\xBF# encoding: us-ascii") # => [[[1, -3], :on_comment, "\xEF\xBB\xBF# encoding: us-ascii", BEG]] ``` For solutions - when there is a byte-order mark I think the column information should either always start at 0, or always start at -3. Then for the encoding comment, it should probably not show up as part of the value, or it should show up for all comments. -- https://bugs.ruby-lang.org/

2 2