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=-2.8 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no 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 F24191F461 for ; Mon, 26 Aug 2019 22:22:39 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 06DE8120B27; Tue, 27 Aug 2019 07:22:32 +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 60043120A0B for ; Tue, 27 Aug 2019 07:22:30 +0900 (JST) Received: by filter0012p3iad2.sendgrid.net with SMTP id filter0012p3iad2-3978-5D645BA8-4D 2019-08-26 22:22:33.007584617 +0000 UTC m=+941941.024433867 Received: from herokuapp.com (unknown [54.242.199.255]) by ismtpd0045p1mdw1.sendgrid.net (SG) with ESMTP id Tw4_jmJrTtyp7yYuL7PRgQ for ; Mon, 26 Aug 2019 22:22:32.860 +0000 (UTC) Date: Mon, 26 Aug 2019 22:22:33 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70143 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15992 X-Redmine-Issue-Author: naruse X-Redmine-Sender: Eregon 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr0S7FHNzOyfJ8v3jahbP2?= =?us-ascii?Q?R3D8nC=2FqrB8eV5fEUXm054YbzIDnuXLsoI1Thnm?= =?us-ascii?Q?w9Ts0mU0DdfKBBrRu4=2F49F1aCFrEvVHF4ibzt0Z?= =?us-ascii?Q?z0D6tdBW162PLOh0ueudXJVqBo5kPQuURVc1ocB?= =?us-ascii?Q?Shypelr34OQ5GFNYR7b5zw7Yx2J50SZ3nBw=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94591 Subject: [ruby-core:94591] [Ruby master Bug#15992] An exception breaks monitor state and cause deadlock 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 #15992 has been updated by Eregon (Benoit Daloze). Should `mon_enter` and `mon_exit` use `Thread.handle_interrupt` inside their method definitions, so they are safe when called directly too? `Thread.handle_interrupt(Exception => :never)` seems too much for `mon_enter`, I think `Thread.handle_interrupt(Exception => :blocking)` would be better. Otherwise, it's not possible to interrupt a thread trying to get a contended monitor with `Thread#raise`: ``` ruby -rmonitor -e 'o=Object.new.extend(MonitorMixin); Thread.new{ o.mon_enter; sleep }; sleep 0.1; Thread.new{sleep 3; p :kill; Thread.main.raise "bye"}; p o.synchronize { p :in; sleep }' ``` Never exits on trunk, but it does exit on 2.6.2 and before. Even Thread#kill does not help. Ctrl+C does interrupt it, because signal traps are not yet supported by `handle_interrupt`, but that might change. ---------------------------------------- Bug #15992: An exception breaks monitor state and cause deadlock https://bugs.ruby-lang.org/issues/15992#change-81063 * Author: naruse (Yui NARUSE) * Status: Closed * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.5: DONE, 2.6: DONE ---------------------------------------- lib/monitor.rb provides Monitor. But its state handling is weak for interrupts caused by Thread.kill for example timeout libraries. Timeout exception may happen everywhere. If it raised when the thread is executing ```ruby def mon_exit mon_check_owner @mon_count -=1 if @mon_count == 0 @mon_owner = nil # HERE!!! @mon_mutex.unlock end end ``` It breaks the state of the monitor and it causes deadlock. -- https://bugs.ruby-lang.org/