On Jul 20 09:03, Ken Brown wrote: > On 7/20/2015 7:20 AM, Corinna Vinschen wrote: > >On Jul 19 10:37, Corinna Vinschen wrote: > >>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. > > > >I uploaded snapshots as well as a 2.2.0-0.1 test release. Please > >give it a try. > > Everything is fine as far as emacs is concerned. I'll rebuild clisp and > test it later today.
Great, thanks for testing! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpq5HTotVt_c.pgp
Description: PGP signature