This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Jul 18 14:41, Eric Blake wrote: > On 07/18/2015 02:11 PM, Corinna Vinschen wrote: > > So in fact, MINSIGSTKSZ is supposed to only amount for the very minimum > > anyway. That would make 16K for MINSIGSTKSZ much more feasible *iff* > > we'd need the _cygtls copy. > > > > The longer I play with this, the less it seems likely we really need the > > _cygtls copy. In fact, it even seems to be a bad idea to do that > > because it requires to change the stack addresses in the TEB, which > > would break in an awful way as soon as the handler calls siglongjmp or > > (the very new) setcontext or swapcontext. > > And the libsigsegv testsuite makes it look like you already got > siglongjmp out of the alternate stack back to the main stack working > correctly, without needing _cygtls, since that's what > tests/stackoverflow2.c does. Yes, that works, thanks to Ken's help debugging the new alternate stack. > > 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. > At any rate, since I only turned up three clients of libsigsegv that > were using the now-outdated advice on how to supply a missing SIGSTKSZ, > and two of those are mine, I can go ahead and rebuild those packages to > just use the larger buffer from the get-go, without waiting for a cygwin > 2.2. Ok. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpLBUgYTXRBH.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |