From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id E60331F4C0 for ; Fri, 25 Oct 2019 21:31:19 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 748C4120BCA; Sat, 26 Oct 2019 06:31:09 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id BF685120BC8 for ; Sat, 26 Oct 2019 06:31:06 +0900 (JST) Received: by filter0186p3mdw1.sendgrid.net with SMTP id filter0186p3mdw1-13118-5DB3699E-B 2019-10-25 21:31:10.115614133 +0000 UTC m=+341438.880950632 Received: from herokuapp.com (unknown [18.208.173.77]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id kSj7IfRdSfqPINrKB7xSGQ for ; Fri, 25 Oct 2019 21:31:10.026 +0000 (UTC) Date: Fri, 25 Oct 2019 21:31:10 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71146 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16278 X-Redmine-Issue-Author: cristiangreco X-Redmine-Sender: jeremyevans0 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BIOx+K++LUfVy5sOuKodiLW=2F7VGQQahN879N2bS?= =?us-ascii?Q?OkTkun4UcgqjQ+fiiYgBX2RLq7sLT4SNegs36t7?= =?us-ascii?Q?kPVCVt6=2FjkmMePDsVsHPUndW3wTzAadMBGORcBM?= =?us-ascii?Q?A7moRh2cbf199TIPzNuE=2FVPXdGwdp5CDP5g=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95554 Subject: [ruby-core:95554] [Ruby master Bug#16278] Potential memory leak when an hash is used as a key for another hash X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16278 has been updated by jeremyevans0 (Jeremy Evans). cristiangreco (Cristian Greco) wrote: > Using each store I found that the 3 labels hashes are retained after garbage collection (all the stores use a similar pattern of storing labels hashes within another hash). > > What do you think is going on here? `object_id` is only unique for the life of the object. After the object is garbage collected, the same `object_id` could be used for a different object. So measuring using `object_id` is not a good idea. Maybe use `ObjectSpace.define_finalizer` in your testing? I'm not sure this affects your particular test program, it is just a good general principle. Can you remove the usage of `Prometheus` in your test script, and design a test script using only core Ruby classes, so we can be sure that `Prometheus` is not holding any references to the hashes? ---------------------------------------- Bug #16278: Potential memory leak when an hash is used as a key for another hash https://bugs.ruby-lang.org/issues/16278#change-82332 * Author: cristiangreco (Cristian Greco) * Status: Open * 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/