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

[ruby-core:111849] [Ruby master Bug#19348] GVL being released earlier than expected when loading iseqs
by st0012 (Stan Lo) 25 Jan '23

25 Jan '23

Issue #19348 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #19348: GVL being released earlier than expected when loading iseqs https://bugs.ruby-lang.org/issues/19348 * Author: st0012 (Stan Lo) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When using the `debug` gem in a Rails app with Ruby 3.2, I noticed that if the VS Code editor connects to the debugger during the app boot, this error could occur: ``` DEBUGGER: ReaderThreadError: uninitialized InstructionSequence ┃ DEBUGGER: Disconnected. ┃ ["/opt/rubies/ruby-3.2.0/lib/ruby/gems/3.2.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:247:in `absolute_path'", ┃ "/opt/rubies/ruby-3.2.0/lib/ruby/gems/3.2.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:247:in `block in iterate_iseq'", ┃ "/opt/rubies/ruby-3.2.0/lib/ruby/gems/3.2.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:246:in `each_iseq'", ... ``` After investigating it with @peterzhu2118, we found that it's because: 1. During the Rails app's boot time, it uses `bootsnap` to load iseqs, which uses the [`ibf_load_iseq_each `](https://github.com/ruby/ruby/blob/9399352a43253e2905d76d21774fb0301069197b/compile.c#L12125) function underneath. 2. After commit [e35c528d721d209ed8531b10b46c2ac725ea7bf5](https://github.com/ruby/ruby/comm… (added in 3.2), that function starts calling `rb_vm_pop_frame` at the end of execution. 3. Because `rb_vm_pop_frame` triggers the release of GVL, iseqs that just being loaded now become accessible by other threads, even though they're not ready to be used. 4. Now, if the `debug` gem calls [`ObjectSpace.each_iseq`](https://github.com/ruby/debug/blob/0fcfc28acae33ec1c08068fb7c33703cfa681fa7/ext/debug/iseq_collector.c#L61-L67) to [activate a `LineBreakpoint`](https://github.com/ruby/debug/blob/0fcfc28acae33ec1c08068fb7c33703cfa681fa7/lib/debug/breakpoint.rb#L246) from its own thread, it'd gain access to those unready iseqs and try to read their state, which would then cause the [`uninitialized InstructionSequence` error](https://github.com/ruby/ruby/blob/40a9964b893fee5680b455d0e905155be3…. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112018] Invitation to RubyKaigi 2023 in Matsumoto
by Akira Matsuda 25 Jan '23

25 Jan '23

Hi, Ruby developers! Let me announce that registration for RubyKaigi 2023 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/2023/with/owd7t54a-ii Your account name listed on the committer email list (https://github.com/ruby/ruby-commit-hook/blob/master/config/email.yml) SVN account name, Redmine account name, or something like that that identifies you as a Ruby core committer. Also, RubyKaigi wants talk proposals from true Ruby hackers like you. Our CFP form is already open, and will be closed in less than a week. Please submit! Now! https://cfp.rubykaigi.org/events/2023 All right! Looking forward to seeing everyone in Matsumoto! -- Akira Matsuda<ronnie(a)dio.jp>

1 0

[ruby-core:111979] [Ruby master Bug#19369] Small corner-case issue that breaks Ractor isolation: change cloned object from another thread
by luke-gru (Luke Gruber) 25 Jan '23

25 Jan '23

Issue #19369 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19369: Small corner-case issue that breaks Ractor isolation: change cloned object from another thread https://bugs.ruby-lang.org/issues/19369 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I was looking into how objects are traversed for deep cloning and I came up with a way to break it. I don't think it'll ever happen in real life so it's not really an issue, just an interesting case. Run with warnings disabled. ```ruby obj = Object.new p "unshareable obj:", obj UNSHAREABLE = obj GO = false SET = false class Object attr_accessor :unshareable def initialize_clone(orig) puts "Clone called for #{orig.inspect}, self = #{self.inspect}" _self = self if orig == UNSHAREABLE t = Thread.new do puts "In thread" Thread.pass until GO puts "Setting unshareable!" # this must be done in separate thread to bypass object traversal deep-cloning _self.unshareable = UNSHAREABLE Object.const_set(:SET, true) end end super(orig) end end r = Ractor.new(obj) do |o| puts "from r#{Ractor.current.object_id} obj #{o.inspect}" GO = true loop until SET p "from ractor, got unshareable:", o.unshareable end r.take ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:111995] [Ruby master Bug#19373] Segmentation fault at 0x00000003000179e8 when running pod install on an M1
by jadephare＠gmail.com (Jade Thornton) 24 Jan '23

24 Jan '23

Issue #19373 has been reported by jadephare(a)gmail.com (Jade Thornton). ---------------------------------------- Bug #19373: Segmentation fault at 0x00000003000179e8 when running pod install on an M1 https://bugs.ruby-lang.org/issues/19373 * Author: jadephare(a)gmail.com (Jade Thornton) * Status: Open * Priority: Normal * ruby -v: 2.7.5 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- All the logs are in the files. Context: I'm trying to run pod install on a react native project that requires a ruby version of 2.7.5 after a react native upgrade. Others on my team have been able to build their projects so I think this is specific to M1 machines. I can reinstall the whole react native project but would rather not if I can avoid it and find a fix. ---Files-------------------------------- Screenshot 2023-01-20 at 3.57.30 PM.png (1.8 MB) Untitled (93.5 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:112009] [Ruby master Feature#15778] Expose an API to pry-open the stack frames in Ruby
by Eregon (Benoit Daloze) 24 Jan '23

24 Jan '23

Issue #15778 has been updated by Eregon (Benoit Daloze). gsamokovarov (Genadi Samokovarov) wrote in #note-16: > What if we settle for an API and implement and test it first in the `debug` gem? The `debug` gem does need/has similar functionality for post-mortem debugging. That way, gems like `web-console` can depend on the `debug` standard gem which I would expect more people to have, instead of using custom C extension. Other tooling can get debug APIs from the `debug` gem as well. It seems like a good place to start because we can test the APIs in real project and get real feedback. One concern I have about that is currently the `debug` gem only supports CRuby, and uses some CRuby-private APIs under RubyVM (I filed https://github.com/ruby/debug/issues/887) I think that should be fixed at some point as I don't think the usages of RubyVM are critical in the `debug` gem, but that work is not done and it's hard to be sure until then. I would advise to use https://github.com/banister/debug_inspector instead of the `debug` gem if you need this functionality. That's a gem literally just to expose that API. It should work fine on TruffleRuby since TruffleRuby support the debug_inspector C API, I'll make a PR there. Not sure about JRuby, but JRuby devs could probably add support in that gem too. ---------------------------------------- Feature #15778: Expose an API to pry-open the stack frames in Ruby https://bugs.ruby-lang.org/issues/15778#change-101442 * Author: gsamokovarov (Genadi Samokovarov) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Hello, I'm the maintainer of the web-console (https://github.com/rails/web-console/) gem, where one of our features is to jump between the frames in which an error occurred. To accomplish this, I currently use the Debug Inspector CRuby API. I think we should expose this functionality in Rubyland, so tools like web-console don't need to resort to C code for this. This also makes it quite harder for me to support different implementations like JRuby or TruffleRuby as everyone is having a different way to create Ruby Binding objects that represent the frames. Here the API ideas: Add `Thread::Backtrace::Location#binding` method that can create a binding for a specific caller of the current frame. We can reuse the existing `Kernel.caller_locations` method to generate the array of `Thread::Backtrace::Location` objects. We can optionally have the `Kernel.caller_locations(debug: true)` argument if we cannot generate the bindings lazily on the VM that can instruct the VM to do the slower operation. - `Thread::Backtrace::Location#binding` returns `Binding|nil`. Nil result may mean that the current location is a C frame or a JITted/optimized frame and we cannot debug it. We can also expose the DebugInspector API directly, as done in the https://github.com/banister/debug_inspector gem, but for tools like web-console, we'd need to map the bindings with the backtrace, as we cannot generate Bindings for every frame (C frames) and this needs to be done in application code, so I think the `Thread::Backtrace::Location#binding` is the better API for Ruby-land. Such API can help us eventually write most of our debuggers in Ruby as right now we don't have a way to do Post-Mortem debugging without native code or even start our debuggers without monkey-patching `Binding`. I have presented this idea in a RubyKaigi's 2019 talk called "Writing Debuggers in Plain Ruby", you can check-out the slides for more context: http://kaigi-debuggers-in-ruby.herokuapp.com. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111907] [Ruby master Bug#19354] Issues with arguments validation in IO.read
by andrykonchin (Andrew Konchin) 24 Jan '23

24 Jan '23

Issue #19354 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19354: Issues with arguments validation in IO.read https://bugs.ruby-lang.org/issues/19354 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.2.1, 3.2.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I've noticed a strange error message when `IO.read` is called with additional positional argument: ```ruby IO.read("a.txt", 3, 0, {mode: "r+"}) # (irb):2:in `read': wrong number of arguments (given 3, expected 0..2) (ArgumentError) ``` But I would expect receiving `given 4, expected 1..3` as far as the first argument (file name) is mandatory and all the other arguments - are optional. I've encountered another related issue - looks like existing of a file with specified name is checked **before** number of arguments. So when passed additional argument and specified a name of not existing file - I receive error about wrong file name, but would expect more basic and essential error about wrong number of arguments: ```ruby IO.read("b.txt", 3, 0, {mode: "r+"}) # (irb):3:in `read': No such file or directory @ rb_sysopen - b.txt (Errno::ENOENT) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111811] [Ruby master Bug#19339] Defining ivar on special constants with @ syntax causes segv
by luke-gru (Luke Gruber) 24 Jan '23

24 Jan '23

Issue #19339 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19339: Defining ivar on special constants with @ syntax causes segv https://bugs.ruby-lang.org/issues/19339 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby 1.instance_eval do @a = 1 end ``` There's a missing check at the top of vm_setivar_fastpath, should be: ```c if (UNLIKELY(RB_SPECIAL_CONST_P(obj))) { // example code: 1.instance_eval { @a = 1 } rb_check_frozen(obj); // raise FrozenError, because it's always frozen return Qundef; } ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:111960] [Ruby master Bug#19364] Issue with tracepoint enable/disable across ractors
by luke-gru (Luke Gruber) 23 Jan '23

23 Jan '23

Issue #19364 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19364: Issue with tracepoint enable/disable across ractors https://bugs.ruby-lang.org/issues/19364 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This sometimes segfaults: ```ruby def test_enable_disable_in_multiple_ractors_with_target rs = [] 100.times do |i| # setup new iseqs Kernel.define_method :"my_method_to_change_for_tracing_#{i}" do true end end 100.times do |i| rs << Ractor.new(i) do |j| meth = :"my_method_to_change_for_tracing_#{j}" tp = TracePoint.new(:line) { } # local to ractor 100.times do tp.enable(target: method(meth)) # change iseq internals of given method, should be done with lock tp.disable # disable hooks should hold lock too, changes method definition internals end end end rs.each(&:take) # shouldn't raise end test_enable_disable_in_multiple_ractors_with_target() ``` Changing iseq internals is done without the VM lock. This is true in Tracepoint#enable and Tracepoint#disable methods. I have a patch coming. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111971] [Ruby master Bug#19368] Ractor.make_shareable issue/inconsistency when proc has been run that acesses outers through eval
by luke-gru (Luke Gruber) 22 Jan '23

22 Jan '23

Issue #19368 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19368: Ractor.make_shareable issue/inconsistency when proc has been run that acesses outers through eval https://bugs.ruby-lang.org/issues/19368 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` a = Object.new # non-shareable prok = Ractor.current.instance_eval do Proc.new do eval('a') end end prok.call # this should work, we're in the main ractor and the proc is not isolated Ractor.make_shareable(prok) # this doesn't currently work, but I think it should. It gives Ractor::IsolationError. See below for reasoning on why I think it should work. # A flag seems to be set on the proc after it's run and accesses outers... ``` Because this work fine: ```ruby a = Object.new # non-shareable prok = Ractor.current.instance_eval do Proc.new do eval('a') end end Ractor.make_shareable(prok) # this works, and it's okay because we get a different error when actually running the shareable proc inside a ractor that accesses outers through eval. ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111967] [Ruby master Bug#19367] Issue with ractor local storage API
by luke-gru (Luke Gruber) 22 Jan '23

22 Jan '23

Issue #19367 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19367: Issue with ractor local storage API https://bugs.ruby-lang.org/issues/19367 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In a non-main ractor, you can do Ractor.main[:key] = 'val', but it only affects storage for Ractor.current, not Ractor.main (which is good!). I think it should throw a RuntimeError if trying to get/set ractor-local storage for non-current ractor. Patch coming. -- https://bugs.ruby-lang.org/

2 2