On Aug 8, 2014, at 5:22 AM, Konstantin Belousov <kostik...@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:

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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to