Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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