This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RESEND] [PATCH] fix allocation of NPTL thread stack guard area
On Wed, 28 May 2008 22:24:35 -0700 (PDT)
"Chris Demetriou" <cgd@google.com> wrote:
> [Resent because a coworker pointed out that the actual patch and other
> attachments enclosed in the last copy was base64 encoded, and that wasn't
> the preferred patch submission format. Sorry!]
>
> I was doing something the other day that required me to set my
> threads' stack and guard sizes. I was surprised to find that NPTL was
> taking the guard area out of the requested stack size, rather than
> tacking the guard area on to the end of the stack.
>
> LinuxThreads allocated the guard area after the end of the requested
> stack. I checked the Solaris 10 pthreads implementation, it does the
> same.
>
> My reading of POSIX.1-2001 pthread_attr_setguardsize says that that
> behavior is right:
>
> 31274 The guardsize attribute controls the size of the guard area for the created thread's stack. The
> 31275 guardsize attribute provides protection against overflow of the stack pointer. If a thread's stack is
> 31276 created with guard protection, the implementation allocates extra memory at the overflow end
> 31277 of the stack as a buffer against stack overflow of the stack pointer.
>
> (Note specifically "allocates *extra* memory.") So, I'm thinking this
> is a bug in NPTL.
If I remember correctly, this issue has been brought up before. The
answer that was given previously was that POSIX is slightly ambiguous
here and glibc is correct in it's current behavior.
I don't particularly agree with that, but that is the stance that has
been taken.
josh