Too low PTHREAD_STACK_MIN value?

[Roger Pau Monné]

Hello,

While debugging a pthread program that sets the stack size of pthreads,
I've found out that the value PTHREAD_STACK_MIN is currently set (2048
bytes) seems to be way too low. As an example, the following simple
program will segfault:

---
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

#define MALLOC_SIZE 1024

void *
foo(void *arg)
{
void *bar;

bar = malloc(MALLOC_SIZE);
assert(bar != NULL);

return (NULL);
}

int main(void)
{
pthread_t thread;
pthread_attr_t attr;
int rc, i;

rc = pthread_attr_init(&attr);
assert(rc == 0);

rc = pthread_attr_setstacksize(&attr, PTHREAD_STACK_MIN);
assert(rc == 0);

rc = pthread_create(&thread, &attr, foo, NULL);
assert(0 == rc);

rc = pthread_join(thread, NULL);
assert(0 == rc);

exit(EXIT_SUCCESS);
}
---

IMHO, PTHREAD_STACK_MIN should be set to a sane value, that allows the
thread to at least make use of libc functions.

Roger.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[David Chisnall]

On 12 Mar 2014, at 02:07, Roger Pau Monné <roge...@citrix.com> wrote:

> I've found out that the value PTHREAD_STACK_MIN is currently set (2048
> bytes) seems to be way too low

This looks like an error in your code. The spec says:

> PTHREAD_STACK_MIN
> Minimum size in bytes of thread stack storage.
> Minimum Acceptable Value: 0

It is meant to be the minimum value that the system can give for a thread stack. The purpose of this constant is for languages that do their own stack management bit some chain of activation records of segmented stacks, but want to use pthreads for threading, so that they can allocate the smallest possible stack that allows pthread cleanup to work.

Using it from C code is very likely to be a mistake.

David

[Ed Maste]

On 11 March 2014 at 20:38, David Chisnall <ther...@freebsd.org> wrote:
> On 12 Mar 2014, at 02:07, Roger Pau Monné <roge...@citrix.com> wrote:
>
>> I've found out that the value PTHREAD_STACK_MIN is currently set (2048
>> bytes) seems to be way too low
>
> This looks like an error in your code. The spec says:
>
>> PTHREAD_STACK_MIN
>> Minimum size in bytes of thread stack storage.
>> Minimum Acceptable Value: 0
>
> It is meant to be the minimum value that the system can give for a thread stack. The purpose of this constant is for languages that do their own stack management bit some chain of activation records of segmented stacks, but want to use pthreads for threading, so that they can allocate the smallest possible stack that allows pthread cleanup to work.
>
> Using it from C code is very likely to be a mistake.

I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal
handler thread it creates[1]. They found it was too small and
implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if
this isn't really the intended use of PTHREAD_STACK_MIN it suggests
the 2K x86 minimum may indeed be too low.

I ran into this while trying LLVM's libunwind, which requires more
stack space. 2K is certainly too low with LLVM libunwind. Is it
reasonable to just increase it to say 8K?

[1] https://github.com/polyml/polyml/blob/6c8add163fc39271da1056e43387a3d33ebd62c6/libpolyml/sighandler.cpp#L527
[2] https://github.com/polyml/polyml/commit/c59360ba74ac99bd9e3d342af214ced39cf0568b
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[David Chisnall]

On 21 Jan 2016, at 16:02, Ed Maste <ema...@freebsd.org> wrote:
>
> I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal
> handler thread it creates[1]. They found it was too small and
> implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if
> this isn't really the intended use of PTHREAD_STACK_MIN it suggests
> the 2K x86 minimum may indeed be too low.
>
> I ran into this while trying LLVM's libunwind, which requires more
> stack space. 2K is certainly too low with LLVM libunwind. Is it
> reasonable to just increase it to say 8K?

I don’t really like this solution. PTHREAD_STACK_MIN is the size for a stack that does not do anything. You should never use it without adding the amount that you are going to need (which might be nothing if you are running code from a language that does not use a conventional C-style stack, but still wants to use OS threads). Making it larger because a specific kind of thing that some consumers want to do with it needs more space is definitely against the spirit of the value and potentially harmful as it means that people using it correctly will be using a lot more memory per thread.

David

[Maxim Sobolev]

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.

On Fri, Jan 22, 2016 at 4:09 AM, David Chisnall <ther...@freebsd.org>
wrote:

--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft

[David Chisnall]

On 23 Jan 2016, at 08:58, Maxim Sobolev <sob...@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.