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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3976 bytes --]

On 07/18/2015 02:11 PM, Corinna Vinschen wrote:
> On Jul 18 12:18, Eric Blake wrote:
>> On 07/17/2015 05:22 PM, Eric Blake (cygwin) wrote:
>>> A new release of libsigsegv, 2.10-2, will soon be available for download
>>> from your favorite mirror.  On 32-bit cygwin, this leaves 2.10-1 as
>>> previous; on 64-bit cygwin, it is a new port of the package, made
>>> possible for the first time by new sigaltstack() code in cygwin 2.1.0.
>>
>> Oddly enough, this new library actually causes a regression in 32-bit m4
>> - with libsigsegv-2.10-1, I get stack overflow handling, but with -2,
>> attempting to register the handler fails and m4 ends up dumping core on
>> stack overflow.  But it's not quite libsigsegv's fault.
> 
> Oh well.  I thought libsigsegv allocates the alternate stack.  If the
> application has to do that by itself anyway, I wonder why use libsigsegv.

libsigsegv manages the fault handling, as well as the
implementation-specifics of how to populate the stack (whether it starts
high and grows low, or starts low and grows high), among other things;
but it still asks the caller to pass in the storage for the alternate
stack (to allow freedom on static vs. malloc'd allocation, which gets
particularly important for applications trying to use libsigsegv for
garbage collection management where the application must roll its own
heap management rather than letting libsigsegv use malloc).

/usr/include/sigsegv.h suggests this for stackoverflow_install_handler():

 * Its size, passed in extra_stack_size, should be sufficiently large.  The
 * following code determines an appropriate size:
 *   #include <signal.h>
 *   #ifndef SIGSTKSZ         / * glibc defines SIGSTKSZ for this
purpose * /
 *   # define SIGSTKSZ 16384  / * on most platforms, 16 KB are
sufficient * /
 *   #endif

which is correct for current Cygwin (because we now define SIGSTKSZ) but
where the old guess for applications compiled on old cygwin was too small.


> 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.

> 
> 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).

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]