From: "byroot (Jean Boussier)" Date: 2022-01-27T09:11:21+00:00 Subject: [ruby-core:107300] [Ruby master Bug#18516] Memory leak on aliasing method to itself Issue #18516 has been updated by byroot (Jean Boussier). Backport changed from 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN to 2.6: WONTFIX, 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED I took the liberty to set the backport field. I was able to repro on 2.6, 2.7,3.0 and 3.1. However 2.6 is security only, I don't think it qualifies. ---------------------------------------- Bug #18516: Memory leak on aliasing method to itself https://bugs.ruby-lang.org/issues/18516#change-96199 * Author: ibylich (Ilya Bylich) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0dev * Backport: 2.6: WONTFIX, 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED ---------------------------------------- The following code produces a memory leak: ```ruby class A 1.upto(Float::INFINITY) do |i| define_method(:"foo_#{i}") {} alias :"foo_#{i}" :"foo_#{i}" remove_method :"foo_#{i}" end end ``` It is very artificial, but it's required for LSAN/Valgrind integration. The reason why it leaks is the following: + alias foo foo increments alias_count even if no alias is created + later during GC rb_free_method_entry is called that in turn calls rb_method_definition_release that calls free only if alias_count + complemented_count == 0. + In this particular case alias_count is 1, and so no cleanup happens. I've been asked to create tickets for memory leaks that I find during LSAN integration if the leak affects previous versions of Ruby. From what I see it does. Possible fix: https://github.com/ruby/ruby/pull/5492. But like I mentioned in PR I'm not sure if it's correct, @nobu mentioned in [my main PR](https://github.com/ruby/ruby/pull/5488) aliasing method to itself is used to swallow some warning on method redefinition, but I don't what's the case there. -- https://bugs.ruby-lang.org/ Unsubscribe: