On Sun, 21 Sep 2014, Julian Elischer wrote:
On 9/20/14, 3:27 AM, John Baldwin wrote:
On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote:
On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote:
On Aug 8, 2014, at 5:22 AM, Konstantin Belousov <kostik...@gmail.com>
wrote:
?
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?s 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? 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.
? Justin
I am conservative to not disturb the address space layout in single go.
If enough people test this setting, I can consider flipping the default
to the reverse.
I am still curious why the things were done in this way, but nobody
replied.
I suspect it was done out of reasons of being overly conservative in
interpreting RLIMIT_STACK. I think it is quite surprising behavior though
and
would rather we make your option the default and implement what the Open
Group
says above.
that is my memory..
The transition from a non threaded app to a threaded app with one thread is
sort of an undefined area.
Feel free to change it if Dan agrees..
I'm all for adopting what POSIX specifies as the default. I
would shy away from adding another knob (LIBPTHREAD_BIGSTACK_MAIN)
if possible.
--
DE
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
