Date: Sat, 23 Jan 2016 12:37:10 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Maxim Sobolev <sobomax@sippysoft.com> Cc: Ed Maste <emaste@freebsd.org>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Too low PTHREAD_STACK_MIN value? Message-ID: <91D206B9-C030-4A7F-AEEF-1C2F141A53E3@FreeBSD.org> In-Reply-To: <CAH7qZfu2bFKePJY4oHkwPH=u8pVfEoGHmZzg3=f_V1NKf0hDZQ@mail.gmail.com> References: <531F42CD.8020307@citrix.com> <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> <CAPyFy2BK6R90pop9v_%2BtW54cv3BoHCQkxBu4-E2fnZ1BptsfHw@mail.gmail.com> <E2C880CC-10A1-40A0-8489-68C6A8DF27F9@FreeBSD.org> <CAH7qZfu2bFKePJY4oHkwPH=u8pVfEoGHmZzg3=f_V1NKf0hDZQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Jan 2016, at 08:58, Maxim Sobolev <sobomax@sippysoft.com> wrote: >=20 > 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=E2=80=99m not sure I was correct in my initial = assessment. The code in pthread=E2=80=99s thread exit routine is = calling the unwinder, and that=E2=80=99s what=E2=80=99s 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=E2=80=99re 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=E2=80=99re allocating their own stack). I=E2=80=99d much prefer a = solution where we don=E2=80=99t expose the HP unwind interfaces from = libeh (it=E2=80=99s fine to do so from a separate libunwind) and we = don=E2=80=99t allocate that much space in the unwinder. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91D206B9-C030-4A7F-AEEF-1C2F141A53E3>