runtime: x_cgo_init determines stacklo incorrectly for some Solaris versions #14865
Comments
Remind me which systems are affected by this and what the effect is? If it's the case that only older Solarises are affected and that the effect is that less stack is used than is actually available (e.g., only 1 MB even though there is arguably 2 GB), then it seems like maybe we can just ignore it and wait for people who need multiple MB of system stack to update to the newer Solaris. |
All versions of Solaris before Solaris 11.0 and potentially any OpenSolaris-based derivatives (SmartOS, Illumos, Tribblix, OpenIndiana, etc.). I have verified that the latest supported release of Solaris 10 exhibits this issue, I am unable to verify which versions of OpenSolaris-based derivatives exhibit this issue, although I would note that there is at least one version of SmartOS where this problem was seen as described in issue #12210. |
agrellum@claudville: |
This is basically a continuation of issue #12210.
As @rsc guessed, Solaris grows the stack as faults happen. This behavior is described in section 5.3.5, on page 136 of Mauro, J., & McDougall, R. (2001). Solaris internals: Core kernel components:
Prior to Solaris 11 (e.g. OpenSolaris and derivatives), when the stack size was set to unlimited, libc_init() (which is responsible for the initialization of the main stack) would set ss_size = 0 and ss_sp = ul_stktop initially and would then update that as stack faults were encountered.
A simple (naive) test program on a pre-Solaris 11 system:
...produces these results:
There's nothing wrong with the results since posix doesn't require specific behaviors in regards to these values and in fact, getcontext(), et al. are considered obsolete (they were removed from the 2013 version of the posix standard: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap03.html).
Now, on Solaris 11 and later, the same test program when executed produces different results:
As such, for Solaris 11+, the current code in gcc_solaris_amd64.c in
x_cgo_init()
should generally work fine for determining stacklo in the unlimited stack size case.However, for older releases the correct answer is to actually call getrlimit(RLIMIT_STACK, ...) and calculate the low address using rlim_cur (unless it returns -3, RLIM_INFINITY), in which case it can safely assume 2GB.
The text was updated successfully, but these errors were encountered: