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 31A1319C026F for ; Thu, 19 Nov 2015 15:34:22 +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 7054CB5D831 for ; Thu, 19 Nov 2015 16:05:06 +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 D2AAB18CC7B5 for ; Thu, 19 Nov 2015 16:05:06 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 8F7A612047C; Thu, 19 Nov 2015 16:05:05 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o10.shared.sendgrid.net (o10.shared.sendgrid.net [173.193.132.135]) by neon.ruby-lang.org (Postfix) with ESMTPS id 0664E120467 for ; Thu, 19 Nov 2015 16:05:01 +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=Z0CgmsmKKgOX9288E0MY9iWxtRs=; b=RlMWEl5XhBWKNgLltq TpCnJ8BSbRBpqW+uORdEeEQ2vl+R5XtH6BBUJ9QQBRBPfpdgcGAC4OcW6ay/RCtz dNf3G2Fu4MEe5eJKz9vFYL/riEwe17mnRQw9b0cVGfhRTvrY4h4J37MMJUkq9f+t +c1wtrUKMmiPEkOBCX5BKOWlc= Received: by filter0454p1mdw1.sendgrid.net with SMTP id filter0454p1mdw1.20673.564D74981F 2015-11-19 07:04:56.308843048 +0000 UTC Received: from herokuapp.com (ec2-54-167-26-236.compute-1.amazonaws.com [54.167.26.236]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id TBvMPlxvTEGs1ncNGz4-2w for ; Thu, 19 Nov 2015 07:04:56.377 +0000 (UTC) Date: Thu, 19 Nov 2015 07:04:56 +0000 From: ko1@atdot.net 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: 46235 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11549 X-Redmine-Issue-Author: charlez X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: ko1 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS5TI5dsG4bindNJqs+v/cSJ1dhK4z7t2T8A1A KB3epP5xnqAsSPeYqcMoPS/j06OIctLwc3iGy2ItGVlyDRVFCiKCk7cNzgrfheoy9WmE8aHD/jthZ+ Vusxn6Tmm1zlQkXQKwPP9T+8eBjwZXbUYm/0 X-ML-Name: ruby-core X-Mail-Count: 71572 Subject: [ruby-core:71572] [Ruby trunk - Bug #11549] [Feedback] 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 updated by Koichi Sasada. Status changed from Open to Feedback Sorry for late response. > * Does Ruby garbage collection potentially run within each thread context? No. Only one Ruby threads run and do GC. One possibility to violate this rule is that running Ruby code in C extensions, rb_thread_call_without_gvl(). So that if you don't use any suspicious C extensions, it can be an interpreter's bug. I'm happy if you give us small example which we can reproduce this issue. > * If answer to prior question is 'Yes', then how can object allocation be prevented when a sibling thread is attempting garbage collection? skip. * 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? One approach is using multiple processes. ---------------------------------------- Bug #11549: Object allocation during garbage collection phase terminates the Ruby process https://bugs.ruby-lang.org/issues/11549#change-54954 * Author: Charles Leu * Status: Feedback * Priority: Normal * Assignee: Koichi Sasada * 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/