From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 21:47:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FE50D31 for ; Mon, 15 Sep 2014 21:47:51 +0000 (UTC) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64AF7603 for ; Mon, 15 Sep 2014 21:47:50 +0000 (UTC) Received: from jt-mbp.sldomain.com (slboulder.spectralogic.com [192.30.190.3] (may be forged)) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8FLlkYJ025228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Sep 2014 15:47:48 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: multipart/signed; boundary="Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: libthr and main thread stack size From: "Justin T. Gibbs" In-Reply-To: <20140808112201.GC93733@kib.kiev.ua> Date: Mon, 15 Sep 2014 15:47:41 -0600 Message-Id: References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> <53E48B38.9010607@ivan-labs.com> <20140808112201.GC93733@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1878.6) X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ivan A. Kosarev" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 15 Sep 2014 21:47:51 -0000 --Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 8, 2014, at 5:22 AM, Konstantin Belousov = wrote: =85 > Below is the patch which adds environment variable = LIBPTHREAD_BIGSTACK_MAIN. > Setting it to any value results in the main thread stack left as is, = and > other threads allocate stack below the area of RLIMIT_STACK. Try it. > I do not want to set this behaviour as default. Is there a reason this should not be the default? Looking at the = getrlimit() page on the OpenGroup=92s site they say: RLIMIT_STACK This is the maximum size of the initial thread's stack, in bytes. The = implementation does not automatically grow the stack beyond this limit. = If this limit is exceeded, SIGSEGV shall be generated for the thread. If = the thread is blocking SIGSEGV, or the process is ignoring or catching = SIGSEGV and has not made arrangements to use an alternate stack, the = disposition of SIGSEGV shall be set to SIG_DFL before it is generated. Does posix say something different? I ran into this issue when debugging a segfault on Postgres when running = an (arguably quite bogus) query that should have fit within both the = configured stack rlimit and Postgres=92 configured stack limit. The = Postgres backend is really just single threaded, but happens to pull in = libpthread due to the threading support in some of the libraries it = uses. The segfault definitely violates POLA. =97 Justin --Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUF159AAoJED9n8CuvaSf4rikIAId5wOQQ2j3/kP6ilnInpmNp PH8YkuKrB2aWt7FFJkIw12VKMq75asmUPYz/Vxud/VAC73QMurrkWsxRowouHVO0 XLkJfcOwFtHOja0MmD5sGEgkShetv3yI2ZgjEQa0MXjI/rzxBCJQOviSNuVyH723 t3qtjnN72hj6QTSK39c0aoN9beXgjICDZkE+7PVuGO6m13dsJcqu2CqAfA9ycFKq qXo0G7iOFzM2QChXMO51Z9xz2hOnaqXmFY6iS3E0fVNlKNgzd8QMB0sLQvEajHbu 96N7QKp+JPMGObd+1pCzXqWuX3OCESMIqbNWKfolbgVV8qKMsGegws4CEPJ0ns4= =gypO -----END PGP SIGNATURE----- --Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2--