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 F121617DC7C7 for ; Thu, 20 Nov 2014 06:38:18 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 7768FB5D866 for ; Thu, 20 Nov 2014 06:27:53 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 1687997A826 for ; Thu, 20 Nov 2014 06:27:54 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iW-c5A_mPcu for ; Thu, 20 Nov 2014 06:27:53 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id EA31697A820 for ; Thu, 20 Nov 2014 06:27:53 +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 597C595241E for ; Thu, 20 Nov 2014 06:27:53 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E99901204F1; Thu, 20 Nov 2014 06:27:34 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTP id 59585120458 for ; Thu, 20 Nov 2014 06:26:59 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPSA id C43E81F45D; Wed, 19 Nov 2014 21:26:54 +0000 (UTC) Date: Wed, 19 Nov 2014 21:26:54 +0000 From: Eric Wong To: Ruby developers Message-ID: <20141119212654.GA31069@dcvr.yhbt.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 66366 Subject: [ruby-core:66366] Re: [ruby-trunk - Bug #10460] Segfault instead of stack level too deep 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" arne@arnebrasseur.net wrote: > Mutant will often generate "broken" code, that's how it works, so > endless recursion could be the result. It needs to be able to detect > somehow that things go wrong. A segfault is actually not the biggest > problem. Mutant forks off workers, so if the worker dies it can assume > something went wrong. Sometimes the code in this ticket also causes > Ruby to get stuck in a futex. In that case the worker is "stuck" and > Mutant becomes unusable. The freezing is likely caused by the stack overflow corrupting memory used by a mutex, putting the mutex in an unrecoverable state. You're better off to detecting lockups in the parent process via periodic checks. > > We may increase the size of the guard area; but that costs memory. > > Right now, on (most) Linux systems, this guard costs 4K (one page) > > per-thread. > > Could you tell me where in the code I can see this? I would love to > investigate this more. Thanks! On GNU/Linux systems, this is done by glibc upon thread creation. We only set the stack size via pthread_attr_setstacksize in thread_pthread.c, but we could also call pthread_attr_setguardsize in the same place.