Date: Mon, 15 Sep 2014 15:47:41 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "Ivan A. Kosarev" <ivan@ivan-labs.com>, freebsd-current@freebsd.org Subject: Re: libthr and main thread stack size Message-ID: <FEB60EB5-546D-454D-AE62-B2483246E42C@scsiguy.com> In-Reply-To: <20140808112201.GC93733@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> <53E48B38.9010607@ivan-labs.com> <20140808112201.GC93733@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kostikbel@gmail.com> = 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FEB60EB5-546D-454D-AE62-B2483246E42C>