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/