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=-4.1 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY 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 253F01F5AE for ; Fri, 14 May 2021 05:03:15 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 9C863120A6E; Fri, 14 May 2021 14:02:08 +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 36D32120A8C for ; Fri, 14 May 2021 14:02:06 +0900 (JST) Received: by filterdrecv-79b6969b64-289qf with SMTP id filterdrecv-79b6969b64-289qf-1-609E048C-AB 2021-05-14 05:03:08.915147062 +0000 UTC m=+619752.261967115 Received: from herokuapp.com (unknown) by geopod-ismtpd-5-2 (SG) with ESMTP id l1eRKSTST5iJy8t3yZvXCw for ; Fri, 14 May 2021 05:03:08.840 +0000 (UTC) Date: Fri, 14 May 2021 05:03:08 +0000 (UTC) From: mame@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17762 X-Redmine-Issue-Author: mame X-Redmine-Issue-Assignee: mame X-Redmine-Sender: mame 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-Redmine-MailingListIntegration-Message-Ids: 79887 X-SG-EID: =?us-ascii?Q?EJh2gqwnyqXtd++xo=2FinyA1V0bXouTB4FkWnzNiKb49ZrVZrl1TlC1LWOOIjSZ?= =?us-ascii?Q?xIxbdkVcdXoymgvgcaq0idMS=2F1=2FBc4Ta5OK63nE?= =?us-ascii?Q?4gZNrFxK5ifqDRc9IRNTfI0IqzlhqUdGsAeRBj1?= =?us-ascii?Q?EPP7uyD2OvhXOHmqHLu5eCCiitJUhbTnZJh6HKn?= =?us-ascii?Q?Z65mySSswfnW6Xazgm6EcaaUS=2FpYYD9YkRg=3D=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103840 Subject: [ruby-core:103840] [Ruby master Feature#17762] A simple way to trace object allocation 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 #17762 has been updated by mame (Yusuke Endoh). Assignee set to mame (Yusuke Endoh) Status changed from Closed to Assigned I realized that the compatibility of this library is not important at all, because this is a tool for human's debugging. Any codebase must not use it. This means that we can change the file name and APIs anytime if needed, even after it is release. So, tentatively, I've committed my proposal as `require "objspace/trace"`. I've heard @ko1 plans to create `lib/debug/run.rb` to enable a new debugger feature that he is now developing. `require "debug/run"` sounds simple and great to me, so I think `require "objspace/trace"` is also good enough. However, I'm okay to change if many people prefer `require "objspace/start_tracing"`. I admit redefining `Kernel#p` may be radical. But I want to see if it brings any actual issue. I'm not against adding `allocation_location` or something. If anyone wants it too, a pull request is welcome. Just an idea: it might be good to create a rubocop rule to prevent `require "objspace/trace"` from being committed accidentally. ---------------------------------------- Feature #17762: A simple way to trace object allocation https://bugs.ruby-lang.org/issues/17762#change-91960 * Author: mame (Yusuke Endoh) * Status: Assigned * Priority: Normal * Assignee: mame (Yusuke Endoh) ---------------------------------------- How about having a short hand to `ObjectSpace.trace_object_allocations_start`, `ObjectSpace.allocation_sourcefile` and `ObjectSpace.allocation_sourceline`? They are a very powerful tool for debugging and code-reading which allows us to identify an allocation site of an object. Though they are never lightweight, they are the last resort when you try debugging code written by someone else. However, the names are too long for me to remember and to type. Whenever I want to use them, I have to google, copy and paste the names. ## Proposal To enable trace allocations: ``` require "objspace/trace" #=> objspace/trace is enabled ``` To show the allocation site of an object: ``` p obj #=> # @ (file.rb):(lineno) ``` ## Example ``` require "objspace/trace" require "active_support/all" p ActiveSupport::VERSION::STRING #=> "6.1.3.1" @ /home/mame/work/ruby/local/lib/ruby/gems/3.1.0/gems/activesupport-6.1.3.1/lib/active_support/gem_version.rb:15 ``` ## Discussion I've attached a simple patch that is originally authored by @ko1 . * Is the message `objspace/trace is enabled` needed or not? * To stop the trace, you need to use `ObjectSpace.trace_object_allocations_stop`. But, I guess that it is rare that we need to stop it during debugging. * Is it too radical to redefine `Kernel#p`? I think that it is good enough for many cases. When it matters, the original APIs (`ObjectSpace.trace_object_allocations_start`, ...) can be used. ---Files-------------------------------- objspace-trace.patch (631 Bytes) -- https://bugs.ruby-lang.org/