This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]