From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 6E70D19C000C for ; Fri, 25 Sep 2015 10:17:49 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id E830BB5D85E for ; Fri, 25 Sep 2015 10:41:24 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id E3D35952441 for ; Fri, 25 Sep 2015 10:41:23 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 49C2812062A; Fri, 25 Sep 2015 10:41:22 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id B1C9C120526 for ; Fri, 25 Sep 2015 10:41:18 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=RBUoLnUBZE/hvWfi8u8auoaVDlU=; b=y6pf0oA/+ck0L+argr MoIEwcRn5RjlOtPgPnpnKMHuoGXlK2bPJCG4oWcHD/jeuYypAb82LlgrwbH+g07p 1AGC8GIxZjzPeQmZxDN3QjeZZ76r59/KNJMuhlQb42Nom47qbUFoFWxzg2yibNzE 20aZptuoUmdRUAX6GcdIuc0Eo= Received: by filter0509p1mdw1.sendgrid.net with SMTP id filter0509p1mdw1.25358.5604A63B3B 2015-09-25 01:41:15.653624352 +0000 UTC Received: from herokuapp.com (ec2-54-242-244-86.compute-1.amazonaws.com [54.242.244.86]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id pmm-LdFkT0-Ks9cuvrYSXQ for ; Fri, 25 Sep 2015 01:41:12.576 +0000 (UTC) Date: Fri, 25 Sep 2015 01:41:12 +0000 From: charlez.leu@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 45510 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11549 X-Redmine-Issue-Author: charlez X-Redmine-Sender: charlez 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS7BuTZ/Qw2kr/wMdSF1D3tsonDbTdxWDDn6As dFshfzf1LrSjUUXkEwd9Dz+s9ro8WyUn+i8GosGlYBeJhppAwAWFTSzcX9odTe/hlqVxM1V4EgB8ZX B3+mMmCFYwfcctux4PLPy0+xaf3paOKJoem6 X-SendGrid-Contentd-ID: {"test_id":"1443145269"} X-ML-Name: ruby-core X-Mail-Count: 70903 Subject: [ruby-core:70903] [Ruby trunk - Bug #11549] [Open] Object allocation during garbage collection phase terminates the Ruby process 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: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #11549 has been reported by Charles Leu. ---------------------------------------- Bug #11549: Object allocation during garbage collection phase terminates the Ruby process https://bugs.ruby-lang.org/issues/11549 * Author: Charles Leu * Status: Open * Priority: Normal * Assignee: * ruby -v: ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- Multi-Threaded Ruby apps are often problematic; especially so when utilizing thread pools, and scheduling work to worker threads. RE: attached file ruby_2.2.3_obj_alloc_gc_bug.txt Following is the section of sap_consumer_control.rb that is presented by the Ruby interpreter as being the current execution context when the problem occurs. 408: loop do 409: @worker_threads.schedule(@work_queue.pop, &@consumer) 410: @sap_packets_consumed += 1 411: end Notes: * @work_queue is a Ruby Queue (allocated within the main thread) into which a producer thread places work requests. * @worker_threads is a thread pool (allocated within the main thread). * @worker_threads schedule method simply puts a work request into the thread pool's internal work queue. One of the worker threads within the thread pool will consume/effect the work request, by executing the specified consumer Proc. * The main program thread simply loops forever scheduling work to thread pool threads. * It appears that an object is being allocated by virtue of the @work_queue.pop Questions: * Does Ruby garbage collection potentially run within each thread context? * If answer to prior question is 'Yes', then how can object allocation be prevented when a sibling thread is attempting garbage collection? * How does one write multi-threaded Ruby apps on multi-core systems that permit multiple-concurrent execution contexts that don't employ a mutex to effectively single thread the entire app? ---Files-------------------------------- ruby_2.2.3_obj_alloc_gc_bug.txt (49.1 KB) -- https://bugs.ruby-lang.org/