From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 02:03:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52BCC7D1; Sun, 21 Sep 2014 02:03:28 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 219FC7EE; Sun, 21 Sep 2014 02:03:24 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-253-99.lns20.per2.internode.on.net [121.45.253.99]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8L23Ig3026105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 19:03:21 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <541E31E0.8020108@freebsd.org> Date: Sun, 21 Sep 2014 10:03:12 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org Subject: Re: libthr and main thread stack size References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> In-Reply-To: <5242716.s4iaScq0Bu@ralph.baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , deischen@FreeBSD.ORG, "Ivan A. Kosarev" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 02:03:28 -0000 On 9/20/14, 3:27 AM, John Baldwin wrote: > On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote: >> On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: >>> On Aug 8, 2014, at 5:22 AM, Konstantin Belousov >>> wrote: >>> >>> ? >>> >>>> Below is the patch which adds environment variable >>>> LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the >>>> main thread stack left as is, and other threads allocate stack >>>> below the area of RLIMIT_STACK. Try it. I do not want to set this >>>> behaviour as default. >>> Is there a reason this should not be the default? Looking at the >>> getrlimit() page on the OpenGroup?s site they say: >>> >>> RLIMIT_STACK This is the maximum size of the initial thread's stack, >>> in bytes. The implementation does not automatically grow the stack >>> beyond this limit. If this limit is exceeded, SIGSEGV shall be >>> generated for the thread. If the thread is blocking SIGSEGV, or the >>> process is ignoring or catching SIGSEGV and has not made arrangements >>> to use an alternate stack, the disposition of SIGSEGV shall be set to >>> SIG_DFL before it is generated. >>> >>> Does posix say something different? >>> >>> I ran into this issue when debugging a segfault on Postgres when >>> running an (arguably quite bogus) query that should have fit within >>> both the configured stack rlimit and Postgres? configured stack limit. >>> The Postgres backend is really just single threaded, but happens >>> to pull in libpthread due to the threading support in some of the >>> libraries it uses. The segfault definitely violates POLA. >>> >>> ? Justin >> I am conservative to not disturb the address space layout in single go. >> If enough people test this setting, I can consider flipping the default >> to the reverse. >> >> I am still curious why the things were done in this way, but nobody >> replied. > I suspect it was done out of reasons of being overly conservative in > interpreting RLIMIT_STACK. I think it is quite surprising behavior though and > would rather we make your option the default and implement what the Open Group > says above. > that is my memory.. The transition from a non threaded app to a threaded app with one thread is sort of an undefined area. Feel free to change it if Dan agrees..