Date: Sun, 21 Sep 2014 10:03:12 +0800 From: Julian Elischer <julian@freebsd.org> To: John Baldwin <jhb@freebsd.org>, freebsd-current@freebsd.org Cc: Konstantin Belousov <kostikbel@gmail.com>, deischen@FreeBSD.ORG, "Ivan A. Kosarev" <ivan@ivan-labs.com> Subject: Re: libthr and main thread stack size Message-ID: <541E31E0.8020108@freebsd.org> In-Reply-To: <5242716.s4iaScq0Bu@ralph.baldwin.cx> References: <53E36E84.4060806@ivan-labs.com> <FEB60EB5-546D-454D-AE62-B2483246E42C@scsiguy.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kostikbel@gmail.com> >>> 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..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?541E31E0.8020108>