Date: Mon, 22 Sep 2014 09:19:30 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Julian Elischer <julian@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "Ivan A. Kosarev" <ivan@ivan-labs.com>, freebsd-current@freebsd.org Subject: Re: libthr and main thread stack size Message-ID: <Pine.GSO.4.64.1409220917100.26756@sea.ntplx.net> In-Reply-To: <541E31E0.8020108@freebsd.org> References: <53E36E84.4060806@ivan-labs.com> <FEB60EB5-546D-454D-AE62-B2483246E42C@scsiguy.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> <541E31E0.8020108@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Sep 2014, Julian Elischer wrote: > 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.. I'm all for adopting what POSIX specifies as the default. I would shy away from adding another knob (LIBPTHREAD_BIGSTACK_MAIN) if possible. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1409220917100.26756>