Re: Problem with stack size in pthreads

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Thu, 12 Jul 2001, Andreas Jaeger wrote:

> Date: Thu, 12 Jul 2001 13:29:27 +0200
> From: Andreas Jaeger <aj@suse.de>
> To: libc-alpha@sources.redhat.com
> Cc: Hui.Huang@sum.com
> Subject: Problem with stack size in pthreads
>
>
> I got a bug report with threads and JDK.  The problem seems to be that
> the stack of the initial thread is growing larger than expected.  If
> the stack pointer of the initial thread in function thread_self (from
> internals.h) is below __pthread_initial_thread_bos, it's not
> considered in the initial thread.
>
> __pthread_initial_thread_bos is set to 2 * 2MB below the current stack
> pointer aligned to a 2 MB (2MB = STACK_SIZE)  boundary in
> pthread_initialize (pthread.c).
>
> What's the right way to fix this?  AFAIU the initial thread can be
> unlimited and has therefore no limits.

How about making checks for a stack pointer that is getting too
close to __pthread_initial_thread_bos and then adjusting the value.
This should be okay unless the pointer leaps by a huge amount, going from
not-too-close to too-far in one step, or in multiple activations without
any intermittent calls to thread_self.  No static value is good, because
it's not known a priori how the stack will behave. The program could
change its soft limit at run time.  It could make the stack so large
that it overlaps some area where a thread stack could be mapped, so we
can't even assume that the upper bound is determined by the thread stack
mmap area.

An alternative is to declare that the caller is the initial thread
if it cannot be proven that it isn't. For all the other threads,
there is a reliable way to tell, because the stacks are allocated with
guard pages (and as far as blown user stacks go, that's the user's
problem).  So we can assume a thread's stack pointer remains in range.
If the caller's stack pointer is not in a stack that the threads library
mmap'ed, and it's not in a user stack, and it's not the thread manager's
stack, then who else could it be but the initial thread?

Firstly, the intial check against __pthread_initial_bos should
simply be eliminated, along with the variable itself. With the
variable gone, the dilemma about what value it should have evaporates.

Secondly, __pthread_find_self should be modified to return the descriptor
pointer of the intial thread if its search fails. That would cover the
behavior when user stacks are in effect.

Lastly, when default stacks are in effect, the descriptor-finding bit
operation would be subject to a sanity check: does the computed descriptor
pointer refer to the descriptor of a valid, existing thread? If not,
we are looking at a stack pointer of an ``overgrown'' intial thread,
so return a pointer to that.