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-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 390571F5AE for ; Tue, 28 Jul 2020 23:45:25 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id AD124120A71; Wed, 29 Jul 2020 08:44:52 +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 7F92B120A70 for ; Wed, 29 Jul 2020 08:44:51 +0900 (JST) Received: by filterdrecv-p3mdw1-75c584b9c6-phwzs with SMTP id filterdrecv-p3mdw1-75c584b9c6-phwzs-21-5F20B88F-F 2020-07-28 23:45:19.10615747 +0000 UTC m=+2788543.703832142 Received: from herokuapp.com (unknown) by geopod-ismtpd-2-2 (SG) with ESMTP id sFT5rQlIQ3OKQQPOby4zeQ for ; Tue, 28 Jul 2020 23:45:18.986 +0000 (UTC) Date: Tue, 28 Jul 2020 23:45:19 +0000 (UTC) From: XrXr@users.noreply.github.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75175 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 17048 X-Redmine-Issue-Author: alanwu X-Redmine-Sender: alanwu 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?PWg67P6owy8ojUUZg1G=2FQM4Z0jTQ2XLCqLM8Y2L8tUvRFuUPM6+aKANjRFY5CJ?= =?us-ascii?Q?rI5UditADVhg+G9KSYDxX9zVqvK4K8EJ5iTwo9u?= =?us-ascii?Q?PL=2FKi47h2wGg1ggvVDCdpjFd8oXL0215ekiy3Wb?= =?us-ascii?Q?mb25XDi0Csj4a6oHqJbTc5=2F5lRyAT3R9Q2w64lW?= =?us-ascii?Q?s5xZhgiMipqgWh+cKiMDtig9X4XNYnox=2FTRB79h?= =?us-ascii?Q?136x4Kv6GvC1O5Fjk=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99379 Subject: [ruby-core:99379] [Ruby master Bug#17048] Calling initialize_copy on live modules leads to crashes 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 #17048 has been updated by alanwu (Alan Wu). Thank you the code, Nobu! I think with your branch we could even keep `.allocate`, though people wouldn't be able to do much with it. As long as no one is able to call `initialize_copy` after children (iclasses) exist, it's fine. I think I was wrong about the number of places we would have to plug to implement an uninitialized state that resolves the issue. Only the places that make new iclasses need to check for the uninitilaized state, so jsut `prepend`, `include` and maybe refinements. Side note about the branch (57c7f9b), it's possible to get access to an uninitialized module in Ruby land by subclassing from `Module`: ```ruby class Sub < Module def initialize_copy(other) p ancestors end end Sub.new.dup # [#, BasicObject] ``` It doesn't cause anything bad to happen AFAICT. I just found it interesting that the branch adds a normally impossible-to-construct module. Maybe it's a positive because it makes Ruby more weird :D ---------------------------------------- Bug #17048: Calling initialize_copy on live modules leads to crashes https://bugs.ruby-lang.org/issues/17048#change-86784 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal * ruby -v: ruby 2.8.0dev (2020-07-23T14:44:25Z master 098e8c2873) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Here's a repro script ```ruby loop do m = Module.new do prepend Module.new def hello end end klass = Class.new { include m } m.send(:initialize_copy, Module.new) GC.start klass.new.hello rescue nil end ``` Here's a script that shows that it has broken semantics even when it happens to not crash. ```ruby module A end class B include A end module C Const = :C end module D Const = :D end A.send(:initialize_copy, C) p B::Const # :C, makes sense A.send(:initialize_copy, D) p B::Const # :D, makes sense A.send(:initialize_copy, Module.new) p (begin B::Const rescue NameError; 'NameError' end) # NameError, makes sense A.send(:initialize_copy, C) p B::Const # still NameErorr. Weird ``` This example shows that the problem exists [as far back as 2.0.0](https://wandbox.org/permlink/4dVDY9sNXJ803jh8). I think the easiest way to fix this is to forbid calling `:initialize_copy` on modules that have children. Another option is to try to decide on the semantics of this. Though I don't think it's worth the effort as this has been broken for a long time and people don't seem to to be using it. Thoughts? -- https://bugs.ruby-lang.org/