[ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
Mon Jul 20 13:03:00 GMT 2015
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.
More information about the Cygwin-apps