Re: libthr and main thread stack size

On 08/13/2014 01:40 AM, Dimitry Andric wrote:
> 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. :-)

Yes, that was the point: at least some of real programs consume more 
stack space than what we have with the hardcoded libthr's limits. Also, 
it looks a bit weird to me that adding thread support/linking against 
libthr affects how much stack space we can consume and whether it can be 
controlled with ulimit.

The original issue I've run into is one of the Asan's tests:

http://reviews.llvm.org/D4562

--