June 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113835] [Ruby master Misc#19722] DevMeeting-2023-07-13
by mame (Yusuke Endoh) 10 Jul '23

10 Jul '23

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

9 8

[ruby-core:112773] [Ruby master Feature#19521] Support for `Module#name=` and `Class#name=`.
by ioquatix (Samuel Williams) 02 Jul '23

02 Jul '23

Issue #19521 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19521: Support for `Module#name=` and `Class#name=`. https://bugs.ruby-lang.org/issues/19521 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- See https://bugs.ruby-lang.org/issues/19450 for previous discussion and motivation. This proposal introduces `Class#name=` to set the temporary class name. This is an alternative or addition to <https://bugs.ruby-lang.org/issues/19520>. ```ruby c = Class.new do self.name = "fake name" end c = Class.new c.name = "fake name" ``` Alternatively, we could use `set_name`: ```ruby Class.new do set_name "fake_name" end ``` ## Example usage The current Ruby test suite has code which shows the usefulness of this new method: ```ruby def labeled_module(name, &block) Module.new do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_module def labeled_class(name, superclass = Object, &block) Class.new(superclass) do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_class ``` The updated code would look like this: ```ruby def labeled_module(name, &block) Module.new do self.name = name class_eval(&block) if block end end def labeled_class(name, superclass = Object, &block) Class.new(superclass) do self.name = name class_eval(&block) if block end end module_function :labeled_class ``` Because the name cannot be set as part of `.new`, we have to have a separate block to set the name, before calling `class_eval`. I think the ergonomics and performance of this are slightly worse than the [counter proposal](https://bugs.ruby-lang.org/issues/19520). -- https://bugs.ruby-lang.org/

10 30

[ruby-core:114032] [Ruby master Misc#19747] Propose Kevin Newton and Jemma Issroff as core committers
by k0kubun (Takashi Kokubun) 29 Jun '23

29 Jun '23

Issue #19747 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #19747: Propose Kevin Newton and Jemma Issroff as core committers https://bugs.ruby-lang.org/issues/19747 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal ---------------------------------------- # Proposal I'd like to propose Kevin Newton (@kddnewton) and Jemma Issroff (@jemmai) as core committers. Now that YARP [Feature #19741] is merged, I want them to work on YARP's CRuby integration without asking other committers to merge their patches. # Background They have not only authored YARP but also contributed various other things to CRuby. I'll include their message for this proposal. ## Kevin Newton I have been working on [ruby/ruby](https://github.com/ruby/ruby/commits?author=kddnewton) since early 2021. My main contributions so far have been: * **YJIT:** I helped design the IR and then implemented the backend for ARM64 support. * **Constants:** I designed and built a new system for constant caches to improve copy-on-write performance and help invalidate less JIT-ed code. * **YARP:** I designed and built YARP from the ground up, which was recently mirrored into CRuby. I want to continue to contribute to ruby/ruby to help maintain the work I've done so far and build more going forward. Being a committer would make it easier to maintain YARP and more easily respond to questions/concerns. ## Jemma Issroff I have been [an active contributor to ruby/ruby](https://github.com/ruby/ruby/pulls?page=1&q=author%3Ajemmaissrof…. Here are a few highlights of my contributions so far: * **Object Shapes:** I implemented the object shapes technique which fundamentally changed how instance variable access worked, to simplify cache checks, increase cache hits, and decrease runtime checks on instance variables. [I spoke about this work](https://www.youtube.com/watch?v=So-KvN3p-eE) at RubyKaigi 2022. https://bugs.ruby-lang.org/issues/18776 * **YARP:** I made [significant contributions to YARP](https://github.com/ruby/yarp/pulls?q=author%3Ajemmaissroff), including writing the code to mirror it into ruby/ruby. https://bugs.ruby-lang.org/issues/18776 * **Documentation:** I have worked on improving the documentation within ruby/ruby, and migrating the Wiki to make it easier to edit, avoid duplication, and stay up to date. [I spoke about contributing to CRuby](https://www.youtube.com/watch?v=7y6DhXQU4wU) at RubyKaigi 2023. https://bugs.ruby-lang.org/issues/19679 I would like to continue to contribute to Ruby. Specifically, being a Ruby committer will reduce friction as I work to compile YARP's AST into ISeqs and fully integrate YARP into ruby/ruby. # Onboarding Aaron and I have helped them work on the CRuby integration. We will continue to help them as they onboard as Ruby committers. -- https://bugs.ruby-lang.org/

7 7

[ruby-core:114029] [Ruby master Bug#19745] Confirm correct behaviour when attaching private method with `#define_method`/`#define_singleton_method`
by itarato (Peter Arato) 28 Jun '23

28 Jun '23

Issue #19745 has been reported by itarato (Peter Arato). ---------------------------------------- Bug #19745: Confirm correct behaviour when attaching private method with `#define_method`/`#define_singleton_method` https://bugs.ruby-lang.org/issues/19745 * Author: itarato (Peter Arato) * Status: Open * Priority: Normal * ruby -v: HEAD * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Should dynamically added private methods be accessible publicly? See the following example? ```ruby private def bar; end foo = Object.new foo.define_singleton_method(:bar, method(:bar)) foo.bar # No error. ``` The script above runs fine on latest Ruby HEAD. Is this correct to ignore the fact that the added method (`method(:bar)`) is private? This came up during a TruffleRuby investigation (https://github.com/oracle/truffleruby/issues/3134) where the result for the same script is: `private method 'bar' called for #<Object:0xc8> (NoMethodError)` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:114028] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors
by ivoanjo (Ivo Anjo) 27 Jun '23

27 Jun '23

Issue #18464 has been updated by ivoanjo (Ivo Anjo). Aaaahh. It's a shame, but I can understand 😓 . Thanks for the clarification :) ---------------------------------------- Bug #18464: RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors https://bugs.ruby-lang.org/issues/18464#change-103691 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ---------------------------------------- When a Ractor is created whilst a tracepoint for `RUBY_INTERNAL_EVENT_NEWOBJ` is active (registered with `rb_tracepoint_new`/`rb_tracepoint_enabled`), the interpreter crashes with a null pointer dereference with the following backtrace: ``` [BUG] Segmentation fault at 0x0000000000000000 ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] ... -- C level backtrace information ------------------------------------------- /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_print_backtrace+0xf) [0x10a15fadd] vm_dump.c:759 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) vm_dump.c:1045 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) (null):0 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(bug_report_end+0x0) [0x109f96b81] error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_bug_for_fatal_signal) error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(sigsegv+0x52) [0x10a0be3a2] signal.c:964 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff20934d7d] /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(gc_event_hook_body+0x4) [0x109fb9d21] gc.c:2214 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath) gc.c:2486 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath_wb_unprotected) gc.c:2507 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_fill+0x0) [0x109fac92e] gc.c:2543 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of0) gc.c:2553 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of) gc.c:2552 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_wb_unprotected_newobj_of) gc.c:2567 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(io_alloc+0x12) [0x109fd341c] io.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_io) io.c:8483 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_stdio) io.c:8514 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_io_prep_stdin) io.c:8532 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_2+0xf7) [0x10a1058a7] thread.c:802 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_native_cond_initialize+0x0) [0x10a1055fb] ./thread_pthread.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(register_cached_thread_and_wait) ./thread_pthread.c:1099 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_1) ./thread_pthread.c:1054 /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff208ef8fc] ``` (full output is attached). This seems to be because the new Ractor sets up stdio objects (`rb_io_prep_stdin` et. al.), which in turn allocate Ruby objects, before `rb_ec_initialize_vm_stack` is called to set up the initial stack frame. I've attached a patch which works around this by not firing GC event hooks if there is no control frame on the execution context. The patch also includes a test which reproduces the issue using the `objspace` extension; creating a Ractor within an `ObjectSpace.trace_object_allocations` block is enough to trigger the crash. The patch seems to fix things, but if you folk prefer I can also try swapping around the order of `prep_stdio` and `rb_ec_initialize_vm_stack`. ---Files-------------------------------- 0001-Fix-interpreter-crash-caused-by-RUBY_INTERNAL_EVENT_.patch (1.91 KB) crash.log (26.1 KB) ruby_2022-01-08-151326_8927-ktsanaktsidis.crash (18.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114027] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors
by jeremyevans0 (Jeremy Evans) 27 Jun '23

27 Jun '23

Issue #18464 has been updated by jeremyevans0 (Jeremy Evans). ivoanjo (Ivo Anjo) wrote in #note-12: > Can I bother you with a backport to 3.0 as well? Ruby 3.0 is in security maintenance mode, and this does not appear to be a security issue: https://www.ruby-lang.org/en/downloads/branches/ ---------------------------------------- Bug #18464: RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors https://bugs.ruby-lang.org/issues/18464#change-103690 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ---------------------------------------- When a Ractor is created whilst a tracepoint for `RUBY_INTERNAL_EVENT_NEWOBJ` is active (registered with `rb_tracepoint_new`/`rb_tracepoint_enabled`), the interpreter crashes with a null pointer dereference with the following backtrace: ``` [BUG] Segmentation fault at 0x0000000000000000 ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] ... -- C level backtrace information ------------------------------------------- /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_print_backtrace+0xf) [0x10a15fadd] vm_dump.c:759 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) vm_dump.c:1045 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) (null):0 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(bug_report_end+0x0) [0x109f96b81] error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_bug_for_fatal_signal) error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(sigsegv+0x52) [0x10a0be3a2] signal.c:964 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff20934d7d] /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(gc_event_hook_body+0x4) [0x109fb9d21] gc.c:2214 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath) gc.c:2486 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath_wb_unprotected) gc.c:2507 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_fill+0x0) [0x109fac92e] gc.c:2543 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of0) gc.c:2553 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of) gc.c:2552 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_wb_unprotected_newobj_of) gc.c:2567 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(io_alloc+0x12) [0x109fd341c] io.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_io) io.c:8483 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_stdio) io.c:8514 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_io_prep_stdin) io.c:8532 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_2+0xf7) [0x10a1058a7] thread.c:802 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_native_cond_initialize+0x0) [0x10a1055fb] ./thread_pthread.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(register_cached_thread_and_wait) ./thread_pthread.c:1099 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_1) ./thread_pthread.c:1054 /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff208ef8fc] ``` (full output is attached). This seems to be because the new Ractor sets up stdio objects (`rb_io_prep_stdin` et. al.), which in turn allocate Ruby objects, before `rb_ec_initialize_vm_stack` is called to set up the initial stack frame. I've attached a patch which works around this by not firing GC event hooks if there is no control frame on the execution context. The patch also includes a test which reproduces the issue using the `objspace` extension; creating a Ractor within an `ObjectSpace.trace_object_allocations` block is enough to trigger the crash. The patch seems to fix things, but if you folk prefer I can also try swapping around the order of `prep_stdio` and `rb_ec_initialize_vm_stack`. ---Files-------------------------------- 0001-Fix-interpreter-crash-caused-by-RUBY_INTERNAL_EVENT_.patch (1.91 KB) crash.log (26.1 KB) ruby_2022-01-08-151326_8927-ktsanaktsidis.crash (18.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114026] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors
by ivoanjo (Ivo Anjo) 27 Jun '23

27 Jun '23

Issue #18464 has been updated by ivoanjo (Ivo Anjo). Thanks again @nagachika! Can I bother you with a backport to 3.0 as well? I know that one is getting "long in the tooth" in terms of support, but having it fixed would mean this crash would not happen on any of the Ruby releases which support Ractors (3.0/3.1/3.2/...) which would make our usage of tracepoints in the ddtrace gem simpler :) ---------------------------------------- Bug #18464: RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors https://bugs.ruby-lang.org/issues/18464#change-103689 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ---------------------------------------- When a Ractor is created whilst a tracepoint for `RUBY_INTERNAL_EVENT_NEWOBJ` is active (registered with `rb_tracepoint_new`/`rb_tracepoint_enabled`), the interpreter crashes with a null pointer dereference with the following backtrace: ``` [BUG] Segmentation fault at 0x0000000000000000 ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] ... -- C level backtrace information ------------------------------------------- /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_print_backtrace+0xf) [0x10a15fadd] vm_dump.c:759 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) vm_dump.c:1045 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) (null):0 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(bug_report_end+0x0) [0x109f96b81] error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_bug_for_fatal_signal) error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(sigsegv+0x52) [0x10a0be3a2] signal.c:964 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff20934d7d] /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(gc_event_hook_body+0x4) [0x109fb9d21] gc.c:2214 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath) gc.c:2486 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath_wb_unprotected) gc.c:2507 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_fill+0x0) [0x109fac92e] gc.c:2543 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of0) gc.c:2553 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of) gc.c:2552 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_wb_unprotected_newobj_of) gc.c:2567 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(io_alloc+0x12) [0x109fd341c] io.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_io) io.c:8483 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_stdio) io.c:8514 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_io_prep_stdin) io.c:8532 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_2+0xf7) [0x10a1058a7] thread.c:802 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_native_cond_initialize+0x0) [0x10a1055fb] ./thread_pthread.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(register_cached_thread_and_wait) ./thread_pthread.c:1099 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_1) ./thread_pthread.c:1054 /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff208ef8fc] ``` (full output is attached). This seems to be because the new Ractor sets up stdio objects (`rb_io_prep_stdin` et. al.), which in turn allocate Ruby objects, before `rb_ec_initialize_vm_stack` is called to set up the initial stack frame. I've attached a patch which works around this by not firing GC event hooks if there is no control frame on the execution context. The patch also includes a test which reproduces the issue using the `objspace` extension; creating a Ractor within an `ObjectSpace.trace_object_allocations` block is enough to trigger the crash. The patch seems to fix things, but if you folk prefer I can also try swapping around the order of `prep_stdio` and `rb_ec_initialize_vm_stack`. ---Files-------------------------------- 0001-Fix-interpreter-crash-caused-by-RUBY_INTERNAL_EVENT_.patch (1.91 KB) crash.log (26.1 KB) ruby_2022-01-08-151326_8927-ktsanaktsidis.crash (18.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114024] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by marcper (Marcelo Pereira) 26 Jun '23

26 Jun '23

Issue #18743 has been updated by marcper (Marcelo Pereira). Oh, I understood from Matz's initial suggestion that the exceptions should be chained, but I see now what he meant. I've applied the changes you suggested, @nobu. Thank you for clarifying, and for reviewing. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103688 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114021] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors
by nagachika (Tomoyuki Chikanaga) 25 Jun '23

25 Jun '23

Issue #18464 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: REQUIRED to 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ruby_3_2 b422c3523c419b88c6da23a4022ae8864f411b84 merged revision(s) 7bd7aee02e303de27d2cddfc5ef47e612d6782cb. ---------------------------------------- Bug #18464: RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors https://bugs.ruby-lang.org/issues/18464#change-103684 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ---------------------------------------- When a Ractor is created whilst a tracepoint for `RUBY_INTERNAL_EVENT_NEWOBJ` is active (registered with `rb_tracepoint_new`/`rb_tracepoint_enabled`), the interpreter crashes with a null pointer dereference with the following backtrace: ``` [BUG] Segmentation fault at 0x0000000000000000 ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] ... -- C level backtrace information ------------------------------------------- /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_print_backtrace+0xf) [0x10a15fadd] vm_dump.c:759 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) vm_dump.c:1045 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) (null):0 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(bug_report_end+0x0) [0x109f96b81] error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_bug_for_fatal_signal) error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(sigsegv+0x52) [0x10a0be3a2] signal.c:964 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff20934d7d] /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(gc_event_hook_body+0x4) [0x109fb9d21] gc.c:2214 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath) gc.c:2486 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath_wb_unprotected) gc.c:2507 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_fill+0x0) [0x109fac92e] gc.c:2543 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of0) gc.c:2553 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of) gc.c:2552 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_wb_unprotected_newobj_of) gc.c:2567 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(io_alloc+0x12) [0x109fd341c] io.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_io) io.c:8483 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_stdio) io.c:8514 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_io_prep_stdin) io.c:8532 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_2+0xf7) [0x10a1058a7] thread.c:802 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_native_cond_initialize+0x0) [0x10a1055fb] ./thread_pthread.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(register_cached_thread_and_wait) ./thread_pthread.c:1099 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_1) ./thread_pthread.c:1054 /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff208ef8fc] ``` (full output is attached). This seems to be because the new Ractor sets up stdio objects (`rb_io_prep_stdin` et. al.), which in turn allocate Ruby objects, before `rb_ec_initialize_vm_stack` is called to set up the initial stack frame. I've attached a patch which works around this by not firing GC event hooks if there is no control frame on the execution context. The patch also includes a test which reproduces the issue using the `objspace` extension; creating a Ractor within an `ObjectSpace.trace_object_allocations` block is enough to trigger the crash. The patch seems to fix things, but if you folk prefer I can also try swapping around the order of `prep_stdio` and `rb_ec_initialize_vm_stack`. ---Files-------------------------------- 0001-Fix-interpreter-crash-caused-by-RUBY_INTERNAL_EVENT_.patch (1.91 KB) crash.log (26.1 KB) ruby_2022-01-08-151326_8927-ktsanaktsidis.crash (18.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112871] [Ruby master Bug#19529] [BUG] ObjectSpace::WeakMap can segfault after compaction
by byroot (Jean Boussier) 25 Jun '23

25 Jun '23

Issue #19529 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19529: [BUG] ObjectSpace::WeakMap can segfault after compaction https://bugs.ruby-lang.org/issues/19529 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * ruby -v: 3.2.1, 2.7.5p203 * Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Reproduction script: ```ruby wm = ObjectSpace::WeakMap.new obj = Object.new 100.times do |i| GC.compact wm[i] = obj # [BUG] Segmentation fault at 0x0000000000000001 end ``` Crash report: ``` /tmp/weakmap.rb:5: [BUG] Segmentation fault at 0x0000000000000003 ruby 3.2.1 (2023-02-08 revision 31819e82c8) [arm64-darwin22] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0005 p:---- s:0023 e:000022 CFUNC :[]= c:0004 p:0016 s:0017 e:000015 BLOCK /tmp/weakmap.rb:5 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :times c:0002 p:0017 s:0008 E:0025b0 EVAL /tmp/weakmap.rb:3 [FINISH] c:0001 p:0000 s:0003 E:0010b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /tmp/weakmap.rb:3:in `<main>' /tmp/weakmap.rb:3:in `times' /tmp/weakmap.rb:5:in `block in <main>' /tmp/weakmap.rb:5:in `[]=' -- Machine register context ------------------------------------------------ x0: 0x000000016da8a6b0 x1: 0x000000016da8a6a8 x2: 0x000000000000003d x3: 0x0000000000000001 x4: 0x0000000000000000 x5: 0x0000000000000b00 x6: 0x0000600002db4b00 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000016da8a6a8 x20: 0x000000000000003d x21: 0x0000000000000003 x22: 0x0000000000000001 x23: 0x00000001023df7b8 x24: 0x0000000000000001 x25: 0x0000000000000000 x26: 0x00006000027bdf80 x27: 0xffffffffffffffff x28: 0xffffffffffffffff lr: 0x0000000102ca28f0 fp: 0x000000016da8a680 sp: 0x000000016da8a640 -- C level backtrace information ------------------------------------------- /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_bugreport+0x9a0) [0x102d3ba98] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x160) [0x102b5fe14] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(sig_do_nothing+0x0) [0x102c9a354] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x19b63c2a4] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(wmap_aset+0x90) [0x102b88e9c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x239c) [0x102d136c8] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(invoke_block_from_c_bh+0x398) [0x102d36438] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_yield_1+0x7c) [0x102d1f208] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(int_dotimes+0x148) [0x102bff3ec] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x2350) [0x102d1367c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_ec_exec_node+0x12c) [0x102b6b4ac] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(ruby_run_node+0x60) [0x102b6b318] /opt/rubies/3.2.1/bin/ruby(main+0x68) [0x102377f34] ``` Seems to happens since 2.7. -- https://bugs.ruby-lang.org/

6 11