[Bug libc/11787] Program with large TLS segment fails aio_write

["carlos_odonell at mentor dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=11787

Carlos O'Donell <carlos_odonell at mentor dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware    |carlos_odonell at mentor
                   |dot org                     |dot com
   Target Milestone|---                         |2.16

--- Comment #23 from Carlos O'Donell <carlos_odonell at mentor dot com> 2012-03-27 19:08:13 UTC ---
I'm assigning this issue to myself since it seems that nptl/allocatestack.c and
nptl/nptl-ini.c need cleanup regarding the definition of stack.

The fact that POSIX has a seperate set of functions for getting and setting the
guard size indicates that the guard is *not* considered a part of the stack.
Not to mention the POSIX wording "the implementation allocates extra memory"
means that the current GLIBC implementation isn't correct (but one or two pages
doesn't help here). The guard size should be removed from the stack
computation.

Given that the guard size shouldn't be part of the stack size brings even more
doubt on the current practice of placing the static tls and pthread descriptor
into the stack.

Yet another corner case is that using PTHREAD_STACK_MIN as a minimal stack
should get you a thread that starts, but under a system where a variable sized
TLS data region is included you are not guaranteed this at all. In fact using
PTHREAD_STACK_MIN as a size might or might not work which is in my opinion
another failure to meet the principle of "least surprise."

I'm asking for some interpretation help from the Austin Group regarding the
meaning of stack.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.