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

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:



freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to