Issue #20485 has been updated by skhrshin (Shintaro Sakahara). Subject changed from Simple use of Mutex and Fiber makes GC leak objects with singleton method to Simple use of Fiber makes GC leak objects with singleton method Description updated Update: Using Mutex was not necessary. ---------------------------------------- Bug #20485: Simple use of Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485#change-108246 * Author: skhrshin (Shintaro Sakahara) * Status: Open * ruby -v: ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end 1.times { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I change `1.times { Fiber.new {}.resume }` to `Fiber.new {}.resume` or remove `work.add_method`, GC works as expected. Is there any problem at the way to Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was same. -- https://bugs.ruby-lang.org/

Issue #20485 has been updated by skhrshin (Shintaro Sakahara). Changing `1.times` to `[1].each` could reproduce the problem on Ruby 3.3.1 too. ---------------------------------------- Bug #20485: Simple use of Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485#change-108254 * Author: skhrshin (Shintaro Sakahara) * Status: Open * ruby -v: ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end 1.times { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I change `1.times { Fiber.new {}.resume }` to just `Fiber.new {}.resume` or remove `work.add_method`, GC works as expected. Is there any problem at the way to use Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was a little different. The code above didn't reproduce the problem, but if I changed `1.times` to `Mutex.new.synchronize`, it was able to reproduce. -- https://bugs.ruby-lang.org/

Issue #20485 has been updated by byroot (Jean Boussier). Status changed from Open to Closed Looks like a duplicate of https://bugs.ruby-lang.org/issues/19436, fixed in Ruby 3.3 but can't really be backported. ---------------------------------------- Bug #20485: Simple use of Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485#change-108256 * Author: skhrshin (Shintaro Sakahara) * Status: Closed * ruby -v: ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end 1.times { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I change `1.times { Fiber.new {}.resume }` to just `Fiber.new {}.resume` or remove `work.add_method`, GC works as expected. Is there any problem at the way to use Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was a little different. The code above didn't reproduce the problem, but if I changed `1.times` to `Mutex.new.synchronize`, it was able to reproduce. -- https://bugs.ruby-lang.org/

Issue #20485 has been updated by byroot (Jean Boussier). I closed because I tried your repro script with `ruby 3.3.1 (2024-04-23 revision c56cd86388) [arm64-darwin23]` both with `1.times` and `Mutex.new.synchronize` and it doesn't fail. Also your description really fit [Bug #19436], hence why I considered it a duplicate. If you say you can reproduce it on 3.3.1, I'll re-open, but then I have no explanation why it doesn't reproduce on my machine. ---------------------------------------- Bug #20485: Simple use of Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485#change-108262 * Author: skhrshin (Shintaro Sakahara) * Status: Closed * ruby -v: ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end 1.times { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I change `1.times { Fiber.new {}.resume }` to just `Fiber.new {}.resume` or remove `work.add_method`, GC works as expected. Is there any problem at the way to use Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was a little different. The code above didn't reproduce the problem, but if I changed `1.times` to `Mutex.new.synchronize`, it was able to reproduce. -- https://bugs.ruby-lang.org/

Issue #20485 has been updated by byroot (Jean Boussier). @skhrshin if you can reproduce consistently, what could be helpful would be to provide a heap dump like this (use some service list GitHub gist because the output might be big: ```ruby require 'objspace' class Work def add_method singleton_class.define_method(:f) {} end end Mutex.new.synchronize { Fiber.new {}.resume } work = Work.new work.add_method puts ObjectSpace.dump(work) work = nil GC.start num_objs = ObjectSpace.each_object(Work).count unless num_objs.zero? puts '-' * 40 puts ObjectSpace.dump_all(output: :stdout) raise "NG" end ``` That would allow us to trace back what's preventing the object from being garbage collected. ---------------------------------------- Bug #20485: Simple use of Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485#change-108265 * Author: skhrshin (Shintaro Sakahara) * Status: Open * ruby -v: ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end 1.times { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I change `1.times { Fiber.new {}.resume }` to just `Fiber.new {}.resume` or remove `work.add_method`, GC works as expected. Is there any problem at the way to use Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was a little different. The code above didn't reproduce the problem, but if I changed `1.times` to `Mutex.new.synchronize`, it was able to reproduce. -- https://bugs.ruby-lang.org/

Issue #20485 has been updated by byroot (Jean Boussier). Alright, looking at your dump: ```json {"address":"0x7f2b570455b8", "type":"CLASS", "shape_id":2, "slot_size":160, "class":"0x7f2b57045518", "variation_count":0, "superclass":"0x7f2b5707fd30", "name":"Work", "references":["0x7f2b5707fd30", "0x7f2b552d0d98", "0x7f2b704fea00", "0x7f2b552d0b90", "0x7f2b552d0d98", "0x7f2b552d0b68", "0x7f2b552d0b40", "0x7f2b552d0b18", "0x7f2b552d41f0"], "memsize":488, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} ``` This is the `Work` class. ```json {"address":"0x7f2b57045478", "type":"CLASS", "shape_id":2, "slot_size":160, "class":"0x7f2b57045518", "variation_count":0, "superclass ":"0x7f2b570455b8", "real_class_name":"Work", "singleton":true, "references":["0x7f2b552d0bb8", "0x7f2b570455b8", "0x7f2b552d0a50", "0x7f2b704fe910", "0x7f2b552d0a28"], "memsize":384, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} ``` This is the `Work` instance singleton class (`"superclass":"0x7f2b570455b8"`). ```ruby {"address":"0x7f2b552d0bb8", "type":"OBJECT", "shape_id":5, "slot_size":40, "class":"0x7f2b57045478", "embedded":true, "ivars":0, "memsize":40, "flags":{"wb_protected":true}} ``` Is the `Work` instance (`"class":"0x7f2b57045478"`). Using `harb` I can see it's referenced by the `Proc` and the singleton class: ``` harb> print 0x7f2b552d0bb8 0x7f2b552d0bb8: "OBJECT" class: (null) memsize: 40 retained memsize: 40 referenced from: [ 0x7f2b552d0a78 (DATA: proc) 0x7f2b57045478 (CLASS: (null)) ] ``` Which is expected. However following both references, there is no path to the root. So my understanding is simply that one of these references is left on the C stack, and since Ruby's GC is conservative, it cannot know for sure if this is a true reference or not, so it doesn't collect the object. To further prove that this isn't a leak, you could loop in your reproduction script. I suspect the "leaked" objects count will remain at one. ---------------------------------------- Bug #20485: Simple use of Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485#change-108268 * Author: skhrshin (Shintaro Sakahara) * Status: Open * ruby -v: ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end 1.times { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I change `1.times { Fiber.new {}.resume }` to just `Fiber.new {}.resume` or remove `work.add_method`, GC works as expected. Is there any problem at the way to use Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was a little different. The code above didn't reproduce the problem, but if I changed `1.times` to `Mutex.new.synchronize`, it was able to reproduce. -- https://bugs.ruby-lang.org/

Issue #20485 has been updated by byroot (Jean Boussier). Status changed from Open to Closed No worries. This aspect of Ruby GC often confuses people. ---------------------------------------- Bug #20485: Simple use of Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485#change-108275 * Author: skhrshin (Shintaro Sakahara) * Status: Closed * ruby -v: ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end 1.times { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I change `1.times { Fiber.new {}.resume }` to just `Fiber.new {}.resume` or remove `work.add_method`, GC works as expected. Is there any problem at the way to use Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was a little different. The code above didn't reproduce the problem, but if I changed `1.times` to `Mutex.new.synchronize`, it was able to reproduce. -- https://bugs.ruby-lang.org/