From: sacrogemini@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:95571] [Ruby master Bug#16278] Potential memory leak when an hash is used as a key for another hash
Date: Sun, 27 Oct 2019 20:41:27 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-82352.20191027204127.046632d45dd48cdb@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16278.20191023232506@ruby-lang.org
Issue #16278 has been updated by cristiangreco (Cristian Greco).
Thanks both @jeremyevans0 @alanwu for the rich and clear explanations!
----------------------------------------
Bug #16278: Potential memory leak when an hash is used as a key for another hash
https://bugs.ruby-lang.org/issues/16278#change-82352
* Author: cristiangreco (Cristian Greco)
* Status: Rejected
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin18]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
Hi,
I've been hitting what seems to be a memory leak.
When an hash is used as key for another hash, the former object will be retained even after multiple GC runs.
The following code snippet demonstrates how the hash `{:a => 1}` (which is never used outside the scope of `create`) is retained even after 10 GC runs (`find` will look for an object with a given `object_id` on heap).
```ruby
# frozen_string_literal: true
def create
h = {{:a => 1} => 2}
h.keys.first.object_id
end
def find(object_id)
ObjectSpace.each_object(Hash).any?{|h| h.object_id == object_id} ? 1 : 0
end
leaked = create
10.times do
GC.start(full_mark: true, immediate_sweep: true)
end
exit find(leaked)
```
This code snippet is expected to exit with `0` while it exits with `1` in my tests. I've tested this on multiple recent ruby versions and OSs, either locally (OSX with homebrew) or in different CIs (e.g. [here](https://github.com/cristiangreco/ruby-hash-leak/commit/285e586b7193104989f59b92579fe8f25770141e/checks?check_suite_id=278711566)).
Can you please help understand what's going on here? Thanks!
--
https://bugs.ruby-lang.org/
prev parent reply other threads:[~2019-10-27 20:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-16278.20191023232506@ruby-lang.org>
2019-10-23 23:25 ` [ruby-core:95519] [Ruby master Bug#16278] Potential memory leak when an hash is used as a key for another hash cristian
2019-10-23 23:43 ` [ruby-core:95520] " mame
2019-10-24 7:55 ` [ruby-core:95528] " cristian
2019-10-25 6:07 ` [ruby-core:95539] " ko1
2019-10-25 21:18 ` [ruby-core:95553] " cristian
2019-10-25 21:31 ` [ruby-core:95554] " merch-redmine
2019-10-25 22:53 ` [ruby-core:95555] " cristian
2019-10-26 2:21 ` [ruby-core:95557] " merch-redmine
2019-10-26 4:13 ` [ruby-core:95559] " nobu
2019-10-26 12:44 ` [ruby-core:95565] " cristian
2019-10-26 15:23 ` [ruby-core:95566] " merch-redmine
2019-10-26 16:31 ` [ruby-core:95567] " XrXr
2019-10-27 20:41 ` sacrogemini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-82352.20191027204127.046632d45dd48cdb@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).