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 48BAF19C001F for ; Wed, 25 Nov 2015 11:11:56 +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 58D37B5D860 for ; Wed, 25 Nov 2015 11:43:00 +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 B0FFE18CC7B5 for ; Wed, 25 Nov 2015 11:43:00 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 7BBE11204EE; Wed, 25 Nov 2015 11:43:00 +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 F41361204D5 for ; Wed, 25 Nov 2015 11:42:55 +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=BOapWhqRcoVIVkM9MWu8bSOrgbw=; b=OtiFYfwWN/ok8gdH0S /RWuD6mJLRu9bycgOWRXnpi5YBu2qbnF55c0AQ9Y0FICnMHAH+5VpZMBoSaZAJmK gn16LQ9Ljc4oyvo9VrPd/yzzeiomJJ5ZV0FZkL5SA1FV0X2Q2XI2XeNk4R/tD0Z6 6HXAPFYEXdjZBeOi7nVsn022Q= Received: by filter0538p1mdw1.sendgrid.net with SMTP id filter0538p1mdw1.4555.5655202B4C 2015-11-25 02:42:51.525190409 +0000 UTC Received: from herokuapp.com (ec2-54-211-74-147.compute-1.amazonaws.com [54.211.74.147]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id NEFF-GznQuWarCCkYBoQqA for ; Wed, 25 Nov 2015 02:42:51.475 +0000 (UTC) Date: Wed, 25 Nov 2015 02:42:51 +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: 46350 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6AZc4YatR2P7PUBS8Z2YLDgVznh7TMyXZMs4 mRx0WdovnGcnO7qq3HdOdZi0QFLAJRjyOKrPi8FCjx6DGbJuFPq1tjx2EGcEINEKgEMy+5b2i8U57y ExhnNfRfRnEqm6VnAfj2oc9rUJjqmWrrwwYK X-ML-Name: ruby-core X-Mail-Count: 71674 Subject: [ruby-core:71674] [Ruby trunk - Bug #11549] 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. Koichi Sasada wrote: > Charles Leu wrote: > > * Per the C level backtrace information (and my potentially flawed interpretation) it appears that a string is being allocated and gc is being invoked within the context of io_getpartial: > > Yes. But it seems no problem. > > Can you insert a probe by GDB and show all machine level (C level) stack trace for all threads? > [BUG] back trace only shows the current thread back trace. > > ``` > gdb --args [ruby command] > (gdb) run > ... (running) > (gdb) info threads > (gdb) thread [n] (where n is available threads) > (gdb) bt > ... > ``` > > Maybe there is shell like macro to do it automatically, but I don't know how. ---------------------------------------- Bug #11549: Object allocation during garbage collection phase terminates the Ruby process https://bugs.ruby-lang.org/issues/11549#change-55077 * 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) ruby_bug_redis_connection.txt (53.3 KB) -- https://bugs.ruby-lang.org/