libthr and main thread stack size

[Justin T. Gibbs]

On Aug 8, 2014, at 5:22 AM, Konstantin Belousov <kostikbel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140915/f3ab381d/attachment.sig>