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.9 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,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 AC5EC1F97F for ; Tue, 27 Nov 2018 08:00:59 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 38580120E4C; Tue, 27 Nov 2018 17:00:55 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id F2DF5120E48 for ; Tue, 27 Nov 2018 17:00:52 +0900 (JST) Received: by filter0113p3las1.sendgrid.net with SMTP id filter0113p3las1-15940-5BFCF9B0-B 2018-11-27 08:00:48.095122793 +0000 UTC m=+992045.887569071 Received: from herokuapp.com (ec2-54-198-129-161.compute-1.amazonaws.com [54.198.129.161]) by ismtpd0046p1mdw1.sendgrid.net (SG) with ESMTP id W53EUM_ZRryKJa6NkZoC1Q for ; Tue, 27 Nov 2018 08:00:47.895 +0000 (UTC) Date: Tue, 27 Nov 2018 08:00:48 +0000 (UTC) From: mame@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65483 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15346 X-Redmine-Issue-Author: MaxLap 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-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4QB0YhhXD9u9ptM2x6rS+7+IWCBo1MWkJXhh PvG9XryLUfl3qEVcUFIOnbN9WzfFOxEvjEXR3FEVp4e5GaCniKhD7GTd8dQAhZUlGAiAn7wzaT6zs1 Fz3x8OYIWNsqoIASjQRwnoC2hZR+ZOE5Gkm9UGLibo5N4IFLmaRI3qvSyw== X-ML-Name: ruby-core X-Mail-Count: 90087 Subject: [ruby-core:90087] [Ruby trunk Bug#15346] Core dump during GC if covering a special require 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 #15346 has been updated by mame (Yusuke Endoh). The commit was r66025. (I have no idea why the commit is not automatically related to this ticket.) I investigated the reason why lineno is 0. In Ruby bytecode, each instruction has lineno information. However, the ensure clause has no significant code (because the return value of ensure is just discarded), so the compiler does emit no instruction for the code. So, the lineno of the ensure clause cannot be identified, which led to lineno 0. This behavior looks benign, and coverage initialization can ignore them. So, I'd like to make r66025 final for this issue. Let me know if you found any weird behavior. Thank you very much. ---------------------------------------- Bug #15346: Core dump during GC if covering a special require https://bugs.ruby-lang.org/issues/15346#change-75213 * Author: MaxLap (Maxime Lapointe) * Status: Closed * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.6.0dev (2018-11-27 trunk 66002) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- On my environment, (ruby-head, updated today) the following script generates a core dump almost all the time. (I join a core dump to this report) I am running on Ubuntu 16.04, I first saw the problem on Travis-CI and managed to make this much simpler reproduction code. ~~~ ruby # Just setting up a file to require, this could be in a regular file and be required. require 'tempfile' f = Tempfile.new(['ruby', '.rb']) f.write(<<-RUBY) a = 123 begin ensure a end RUBY f.close # Now the actual code to trigger the problem require 'coverage' Coverage.start load f.path # require can do the same thing, but less frequently # The problem is during GC, so we trigger it ourself puts 'gc time!' GC.start # When it doesn't crash the first time, doing the load/require again seems to take care of it puts '2nd gc' load f.path GC.start puts 'gc done, try again!' ~~~ The problem seems related to the content of the ensure, if it's too simple, things break? It's weird. If the content of the ensure is: a puts 'something' #=> All good puts 'something' a #=> Core dump puts 'something'; a #=> All good a + 1 #=> All good My personal guess is, if the last line of the ensure is useless, ruby optimizes it away, but that causes a problem with Coverage. ---Files-------------------------------- cov-require_core_dump.txt (10.4 KB) -- https://bugs.ruby-lang.org/