From owner-freebsd-current@freebsd.org Sat Jan 23 12:37:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF4B2A8BD1A for ; Sat, 23 Jan 2016 12:37:27 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B90751B1F; Sat, 23 Jan 2016 12:37:26 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u0NCbH2d068956 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2016 12:37:18 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Too low PTHREAD_STACK_MIN value? From: David Chisnall In-Reply-To: Date: Sat, 23 Jan 2016 12:37:10 +0000 Cc: Ed Maste , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <91D206B9-C030-4A7F-AEEF-1C2F141A53E3@FreeBSD.org> References: <531F42CD.8020307@citrix.com> <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> To: Maxim Sobolev X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 12:37:28 -0000 On 23 Jan 2016, at 08:58, Maxim Sobolev 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