On 23 Jan 2016, at 08:58, Maxim Sobolev <sobo...@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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"