This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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]

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


Sorry for not getting back to you sooner.  This stuff gives me
a headache.

On Tue, Aug 08, 2006 at 08:09:58AM -0700, Jay wrote:
> I posted this on the alpha mailing list, but this
> might be a better place for it.  From what I
> understand, when __pthread_initial_thread_bos is set
> in pthread.c, it must be set to cover both the initial
> thread and manager thread.  Looking at the
> STACK_GROWS_DOWN case, it looks like this variable is
> set to STACK_SIZE beyond the space it needs to to
> cover the initial and manager thread.  Graphically:
> -------------------   top of initial stack
> | Initial thread  |
> |                 |
> -------------------
> | Manager thread  |
> |                 |
> -------------------
> | Free space      |
> |                 |
> -------------------   __pthread_initial_thread_bos

No.

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.

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?

> When the very first worker thread gets assigned its
> stack space it is getting assigned the space in free
> space which is above __pthread_initial_thread_bos
> (instead of something below
> __pthread_initial_thread_bos as it should since it is
> not part of the initial thread), so when thread_self
> is called from the first worker thread, thread_self
> returns the initial thread, not the worker thread. 
> All other threads created after the first worker
> thread are assigned memory below
> __pthread_initial_thread_bos.  The line that sets
> __pthread_initial_thread_bos is
>   __pthread_initial_thread_bos =
>     (char *)(((long)CURRENT_STACK_FRAME - 2 *
> STACK_SIZE) & ~(STACK_SIZE - 1));
> 
> Changing the 2 in the above equation to a 1 would
> solve the problem of __pthread_initial_thread_bos
> being set beyond the free space depicted above.  Is
> what is depicted above correct and it's a problem with
> the memory the kernel is handing out, or is this a
> bug, and the 2 should be a 1 since the stack is
> growing down?

The kernel is responsible for setting the stack size of the initial
VMA.  The heap used to be way down at the other end of memory and grow
up; but there've been a lot of changes in that respect lately
and it may be that big mmaps on your platform are being placed
directly below the stack.

I think you need to look at the /proc/PID/maps file for a program that
shows this problem.  How big is the stack, really?  And what ulimits
do you have set (ulimit -a) - are they changing the stack size?

-- 
Daniel Jacobowitz
CodeSourcery


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