On Jul 18 14:41, Eric Blake wrote:
On 07/18/2015 02:11 PM, Corinna Vinschen wrote:
OTOH, calling certain Cygwin functions might require lots of stack.
E.g. open/read/write/close requires more than 2K stack, so MINSIGSTKSZ
shouldn't be too small.
So, what about MINSIGSTKSZ == 8192 and SIGSTKSZ == 32768?
Or MINSIGSTKSZ == 16384 and SIGSTKSZ == 65536?
That could go into Cygwin 2.2.0 which I could release next week.
Might help, but feels a little unclean. As I said, old clients of
libsigsegv were using the fallback definition of 16k; setting
MINSIGSTKSZ to 16k would let the sigaltstack() succeed where it is now
failing, but if cygwin ever consumes all 16k rather than the current 400
or so bytes, that leaves nothing for the application (normally, an
application only expects to use SIGSTKSZ - MINSIGSTKSZ for its own use,
if it uses the system-recommended sizing).
Cygwin shouldn't really consume 16K stack by itself when called from the
application. Large buffers should use the tmp_pathbuf facility throughout.
But there are still functions using big stack buffers. I mention them
here for bookkeeping as much as for information and discussion:
- Debugging code in dcrt0.cc, initial_env() uses 96K stack on process
startup. Usually disabled. Non-critical.
- dll_list::alloc, called during DLL initialization uses 64K stack.
Calling dlopen from the alternate stack would be fatal. The buffer
is used in code called under Windows loader lock conditions, so this
could be converted to a static buffer.
- A function called error_start_init uses 32K of stack and is called
if the env var CYGWIN is set to "error_init:...". That's very unlikely
from a SEGV handler. Not nice, but probably non-critical.
- pinfo::status_exit is called when a process exits due to a signal
from Windows. This usually shouldn't happen inside the signal
handler, but it might. pinfo::status_exit uses a 32K buffer.
- Stracing a process ends up using >48K of stack.
That means even the current 32K are not quite sufficient, though, only
in unlikely border cases, apparently.
Anyway, I plan to change this in the next few days. Given this, I'll
set MINSIGSTKSZ to 8K and SIGSTKSZ to 32K in 2.2.