Re: Too low PTHREAD_STACK_MIN value?

From: David Chisnall <theraven_at_FreeBSD.org>
Date: Sat, 23 Jan 2016 12:37:10 +0000
On 23 Jan 2016, at 08:58, Maxim Sobolev <sobomax_at_sippysoft.com> wrote:
> 
> For what it's worth, I agree with David. This looks like definite misuse of the constant. If app X requires min size of stack of Y, it's fullish of it if to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be really using MAX(PTHREAD_STACK_MIN, Y) to set its stack instead. Should be easy to patch and it needs to be reported to the upstream vendor(s) instead. Don't forget that bumping this limit, no matter how small, will get multiplied by the number of threads running, which could be in many thousands

After talking to Ed, I’m not sure I was correct in my initial assessment.  The code in pthread’s thread exit routine is calling the unwinder, and that’s what’s exhausting the stack space.  This means that a thread function that just does return 0 will run out of stack space.

That said, existing values of PTHREAD_STACK_MIN are part of the ABI and if we’re going to bump it then we need to make sure that we do something clever with existing binaries to ensure that, when they ask for 2KB of stack, we give them more (which can be problematic if they’re allocating their own stack).  I’d much prefer a solution where we don’t expose the HP unwind interfaces from libeh (it’s fine to do so from a separate libunwind) and we don’t allocate that much space in the unwinder.

David
Received on Sat Jan 23 2016 - 11:37:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC