[ruby-core:107870] [Ruby master Bug#18516] Memory leak on aliasing method to itself

Issue #18516 has been updated by nagachika (Tomoyuki Chikanaga).

Backport changed from 2.6: WONTFIX, 2.7: REQUIRED, 3.0: REQUIRED, 3.1: DONE to 2.6: WONTFIX, 2.7: REQUIRED, 3.0: DONE, 3.1: DONE

ruby_3_0 6175823bab28b5d12f66371d67d006df37751fbc merged revision(s) 7ff1bf317887c0d7b21e91ad548d07b9f05c540c,e89d80702bd98a8276243a7fcaa2a158b3bfb659.

----------------------------------------
Bug #18516: Memory leak on aliasing method to itself
https://bugs.ruby-lang.org/issues/18516#change-96810

* Author: ibylich (Ilya Bylich)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 3.2.0dev
* Backport: 2.6: WONTFIX, 2.7: REQUIRED, 3.0: DONE, 3.1: DONE
----------------------------------------
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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>