This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Insufficient stack size for threads with __thread data exceeding ARCH_STACK_DEFAULT_SIZE
- From: ilmalakhov <ilmalakhov at yandex dot ru>
- To: libc-help at sourceware dot org
- Date: Mon, 18 Apr 2011 17:39:35 +0400
- Subject: Insufficient stack size for threads with __thread data exceeding ARCH_STACK_DEFAULT_SIZE
Hi,
can anyone explain why static TLS data size is efficiently included into the stack size provided by NPTL to a thread being created? As long as the size of __thread variables exceeds either ARCH_STACK_DEFAULT_SIZE or the corresponding rlimit (provided the latter is set), a newly created thread is left with approximately MINIMAL_REST_STACK bytes long stack which is just a few kilobytes! That's typically not enough for any realistic thread activity. To put it another way, what is the rationale for having MINIMAL_REST_STACK much smaller than ARCH_STACK_DEFAULT_SIZE?
My clients were shocked by Segmentation Fault in the following harmless program at i386-linux host. Some of them insist that MINIMAL_REST_STACK should be made comparable to ARCH_STACK_DEFAULT_SIZE and I'd like to know possible pitfalls.
To reproduce the failure:
$ ulimit -s unlimited
$ ./a.out 20
Segmentation fault
Source:
#include <pthread.h>
#include <stdlib.h>
__thread char g_arr[2 * 1024 * 1024];
static int
f (int arg)
{
char arr[256];
if (arg > 0)
return f (arg - 1);
return 0;
}
static void *
method (void *arg)
{
f ((int) arg);
return NULL;
}
int
main (int argc, char **argv)
{
pthread_t handle;
pthread_create (&handle, NULL, &method, (void *) atoi (argv[1]));
pthread_join (handle, NULL);
return 0;
}
Thanks,
Ilya.