Stack consumption in NPTL



Hi,

We have an application which creates multiple threads and has some
logging mechanism. We observed that the application crashes when
using
NPTL but works just fine with LinuxThreads.
The stack trace analysis revealed that the crash is due to smaller
stack size. We are setting the stack size to 16K through the program
using pthread_attr_setstacksize() function.
Increasing the stack size to 128K did not reproduce the crash. We are
trying to find out the difference in behavior between LinuxThreads
and
NPTL with respect to stack size, pthread_attr_setstacksize() etc.
Does
anyone know about this? What should be the stack size for the threads
in NPTL?


We also created a small program to analyze this difference in
behavior. What the program does is, create a thread with stack size
set to 16K. Call a function having 1K buffer recursively about 20
times, so that the stack should exceed 16K and we get a crash.

For NPTL, the program crashed while making 9th recursive call. And for
LinuxThreads, the program crashed while making 16th recursive call.
This suggests that NPTL consumes stack faster.

Is this the case? Is it documented anywhere?

Below is the sample program.


#include <stdio.h>
#include <iostream>
#include <pthread.h>

#define NUM_ITERATIONS 20

using namespace std;

int numIterations;

void call_my_sprintf(int Iter)
{
char buffer[1024];

buffer[0] = 'A';
buffer[1] = '\0';

if(Iter == 0)
return;

call_my_sprintf(Iter - 1);
return;

}

void *RunThread(void *ignore)
{
call_my_sprintf(numIterations);
return NULL;
}

void SpawnThreadsAndWait(int num_threads)
{
int rc;
pthread_t **threads;

threads = (pthread_t **)malloc(sizeof(pthread_t *) * num_threads);

for(int i=0; i<num_threads; i++)
{
threads[i] = (pthread_t *)malloc(sizeof(pthread_t));
}
pthread_attr_t threadatts;

pthread_attr_init(&threadatts);
int error = pthread_attr_setstacksize(&threadatts, 16 * 1024);
printf("pthread_attr_setstacksize : %d\n", error);

/* Create num_threads threads for this example */
for(int i =0; i<num_threads; i++)
{
rc = pthread_create(
threads[i],
(const pthread_attr_t *)threadatts,
RunThread,
(void *)NULL
);
if (rc != 0) {
perror("main: pthread_create #1");
exit(1);
}
printf("Created thread %d\n", i);
fflush(stdout);
}

sleep(5);
for(int i=0; i<num_threads; i++)
{
rc = pthread_join(*threads[i], NULL);
if (rc != 0) {
perror("SpawnThreadsAndWait: pthread_join");
exit(1);
}
printf("Exited thread %d\n", i);
fflush(stdout);
}

for(int i=0; i<num_threads; i++)
{
free(threads[i]);
}

free(threads);
}

int main(int argc, char **argv)
{

if (argc > 1)
numIterations = atoi(argv[1]);
else
numIterations = NUM_ITERATIONS;

SpawnThreadsAndWait(1);
return 0;
}
.



Relevant Pages

  • Stack Size in NPTL
    ... The stack trace analysis revealed that the crash is due to smaller ... Increasing the stack size to 128K did not reproduce the crash. ... NPTL with respect to stack size, ... void call_my_sprintf ...
    (comp.programming.threads)
  • Re: controlling stack size in RHEL 3.0 pthreads
    ... smaller stack space. ... hardware designs in C++ for those of you familiar ... NPTL and LinuxThread's versions of pthreads? ... You probably have a bug in your program (or request illegal stack ...
    (comp.programming.threads)
  • Re: Stack consumption in NPTL
    ... NPTL but works just fine with LinuxThreads. ... The stack trace analysis revealed that the crash is due to smaller ... Increasing the stack size to 128K did not reproduce the crash. ... NPTL with respect to stack size, ...
    (comp.os.linux.development.apps)
  • Re: Stack consumption in NPTL
    ... analysis revealed that the crash is due to smaller stack size. ... NPTL will reserve 8M of virtual address space per ... Memory Allocation ... data structures and the thread-local storage are placed on the ...
    (comp.os.linux.development.apps)
  • Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
    ... I can find the cause of my crashes, which may or may not be related ... But the use of TOCS in PPC64 make me ... and I think I hit a couple without this code. ... I'm thinking that I'm hitting stack overflows. ...
    (Linux-Kernel)