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

[Ken Brown]

On 7/20/2015 7:20 AM, Corinna Vinschen wrote:
> On Jul 19 10:37, Corinna Vinschen wrote:
>> 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.
>
> 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.

Ken