pthread_get_stacksize_np returns incorrect values for the main thread on OS X 10.9

[jrmuizel]

See:
robovm/robovm#274
https://groups.google.com/forum/#!topic/address-sanitizer/7_abqFZ5wXw
http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011388.html

pthread_get_stacksize_np returns 512KB for the main thread instead of the 8MB that it's supposed to. This causes us to allocate our guard page in the middle of the stack.

[nagisa]

Are we sure OS X doesn’t just put the guard page on the main thread by default?

[jrmuizel]

All of the evidence that I've seen suggests that OS X already has guard pages in place.
https://github.com/opensource-apple/xnu/blob/10.12/bsd/kern/kern_exec.c#L4782

[jrmuizel]

In fact there should be guard pages in place for all other threads too.
See _pthread_allocate in https://opensource.apple.com/source/libpthread/libpthread-218.1.3/src/pthread.c.auto.html

[jrmuizel]

It looks like calling pthread_get_stacksize_np returns all kinds of different things on different versions of OS X.

On 10.8 it gives a hard coded 8MB
10.9 and 10.10 give a hard coded 512KB
10.11 hard codes 8MB
10.12 seems to actual give the correct result (i.e. if the executable has a different stack size specified using LC_LOAD or adjusted using rlimit) This is communicated with an environment variable called main_stack.

It seems like the only way to reliably get the stack size of the main thread is to use mach_vm_region_info()

[alexcrichton]

Discussed during triage today, the conclusion was that this doesn't seem super high priority, so P-medium.

It seems like we should just remove the main stack guard page on OSX like we've already done on Linux.

[ishitatsuyuki]

We can probably use this code as reference:

https://github.com/dmlloyd/openjdk/blob/2f680fec58a8ffb818a48f542e493306d1113c69/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L902-L961

[steveklabnik]

Triage: no changes I'm aware of

[kvark]

Was running on OS 11.3 beta and hit a stack overflow with 512K (in debug).
Edit: nvm, the thread in my case was created elsewhere, not by Rust.

[mqudsi]

I don't know if the rust-lang policy would be to close out this issue that affects a now retired target or not, but fyi macports added a workaround for this issue taken from llvm.

(As noted in the discussion above, pthread_get_stacksize_np() works fine if called from other than the main thread, so the workaround only kicks in if that's not the case.)