This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

Static TLS size and stack size


If I set the desired stack size via pthread_attr_setstacksize in a
pthread_attr_t passed to pthread_create, I don't get a stack of that
size.  The guard page is subtracted from the stack size.  More
importantly, the static TLS size is subtracted.  If the result is
negative, pthread_create returns an EINVAL error.  If the result is
non-negative, I can wind up a stack much smaller than requested.

This is a problem for the Go library.  The Go library uses GCC's
-fsplit-stack support, so when creating a thread it asks for a stack
size of PTHREAD_STACK_MIN.  If the Go library is used by a program with
a large number of TLS variables, or a large TLS array, I can wind up
with an unexpected failure, or with a segmentation violation as the
small stack is overrun.

I tried working around this by calling the glibc-private function
_dl_get_static_tls_info, but, besides being highly nonportable, Jakub
informs me that that will cause rpm to refuse to build a gcc RPM.

I don't see a good way to handle this.  To me it simply seems like a bug
that glibc takes the static TLS size out of the requested stack size.
Why not increase the requested stack size instead?

Any suggestions for what I can do here?

Ian


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