setting of initial bottom of stack variable in pthread.c (again)

[Daniel Jacobowitz]

On Mon, Aug 21, 2006 at 10:07:10AM -0700, Jay wrote:
> > The tops and bottoms of stacks must be aligned to STACK_SIZE in
> > this model.  The initial stack is determined by the OS, and can end
> > up just about anywhere.  Also, it looks to me like the 2* is
> > unnecessary; this is not covering the manager thread.  So the
> > initial thread stack is a bit of alignment padding (up to
> > STACK_SIZE) plus 2*STACK_SIZE.
> 
> I understand that the top and bottom of the stacks
> must be aligned to STACK_SIZE.  I'm having trouble
> with following the last statement.  If the 2* is
> uncessary, why the alignment padding (up to
> STACK_SIZE) plus 2*STACK_SIZE?  I'm really not
> grasping the plus 2*STACK_SIZE at all.

The initial thread stack size _in the current code_ is treated as
alignment + 2*STACK_SIZE.  I think if the 2* were missing, things
would still be OK; then it would be padding + STACK_SIZE.  The 2
has been there for a long long time.

> 
> > 
> > The manager thread stack is allocated later:
> > 
> >   __pthread_manager_thread_bos =
> > malloc(THREAD_MANAGER_STACK_SIZE);
> > 
> > That's on the heap somewhere.  Does that end up
> > above or below the
> > initial thread for you?
> 
> It looks like the manager thread is definetly well
> below the stack.  I put some printfs in pthread.c
> (yes, I know it's very dirty), so you can see the
> output below.

Probably because this comes from the heap; it's a much smaller malloc
allocation (looks like 8K rather than 2MB).

> I haven't found anywhere were the limit is changed
> yet, but something does not look right.  The output
> (see below) from ulimit says that the stack size is
> 8192kB.  The STACK_SIZE variable defined in
> internals.h and used in pthread.c is set to
> 1024*1024*2 (2097152).  Could this be causing a
> problem with these two sizes not being set right?

It shouldn't be a problem unless the limit is < STACK_SIZE
(or maybe 2*STACK_SIZE).

Here is something very strange.

> bfa00000-bfa01000 ---p 00000000 00:00 0
> bfa01000-bfc00000 rwxp 00001000 00:00 0
> bffff000-c0000000 rwxp 00000000 00:00 0

Check with strace -f, please, but I assume that 0xbfa00000
to 0xbfc00000 was allocated using mmap.  0xbfc00000 is only
4MB away from the top of your stack.  Your stack limit is 8MB.
Why is the kernel reallocating something only 8MB below the stack?
If you used 8MB stack you'd clobber it.

I checked the kernel sources and can't see how this could occur;
your kernel may be broken.
-- 
Daniel Jacobowitz
CodeSourcery