On 08 Aug 2014, at 13:22, Konstantin Belousov <kostik...@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
Description: Message signed with OpenPGP using GPGMail