libthr and main thread stack size

[Dimitry Andric]

On 08 Aug 2014, at 13:22, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Fri, Aug 08, 2014 at 12:32:56PM +0400, Ivan A. Kosarev wrote:
>> 
>> On 08/08/2014 09:28 AM, Konstantin Belousov wrote:
>>> On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote:
>>>> Hello,
>>>> 
>>>> According to libthr's thr_init.c (the 9.2 version) init_main_thread()
>>>> allocates s.c. "red zone" below the main stack in order to protect other
>>>> stacks. The size of the main stack is determined by the
>>>> _thr_stack_initial variable that is declared extern though it doesn't
>>>> seem it can be changed. The value of the variable is set to 4M on 64-bit
>>>> platforms which is obviously not sufficient for the most of real programs.
>>>> 
>>>> Can anyone please confirm that there is no way to increase the stack
>>>> size for the main thread and thus any program linked against libthr has
>>>> only a few megabytes of stack memory for its main thread--whatever the
>>>> system stack size (ulimit -s) is set to?
>>> Yes, there is no way to change the main thread stack clamping.
>>> Could you provide a reasonable use case for the 4MB stack ?
>> 
>> Traversing trees with recursive functions or on-stack grammar parsers?

I just ran into a similar issue while running one of clang 3.5's test
cases (see http://llvm.org/PR20635 ).  On i386, it used up approximately
2MB of stack, then ran into the guard page, and segfaulted.

I was quite amazed to find out that ulimit -s didn't help at all, until
I remembered this thread. :-)


>>> Anyway, I somewhat sympathize to the idea to stop clamping the main
>>> thread stack, and to not reuse it for other threads stack carving.
>>> This also means that non-main threads stack allocator should stop
>>> tracking the explicit location for the stacks and rely on vm mmap(2)
>>> base selection instead.
>> 
>> Yes, that would solve the problem.
>> 
>>> I do not know the motivations why the current scheme of stacks allocation
>>> was chosen.  The changes do not look too involved.
> In fact, I can resonably explain the current behaviour. The motivation
> seems to come from desire to interpret the RLIMIT_STACK as the global
> limit to the stack usage by all threads. From this PoV, it becomes clean
> why the other thread stacks are carved from the main stack.

Linux seems to interpret it as the default stack size for *each* new
thread (so I guess that also includes the "main" thread, if Linux has
such a concept):

''On Linux/x86-32, the default stack size for a new thread is 2
megabytes.  Under the NPTL threading implementation, if the RLIMIT_STACK
soft resource limit at the time the program started has any value other
than "unlimited", then it determines the default stack size of new
threads.''


> 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.

It works for my case, thanks.  I'm not sure if we should use Linux's
behavior of using RLIMIT_STACK for *all* threads, but I would definitely
expect that value for the main thread by default...

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140812/b1f9e132/attachment.sig>