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

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

[Eric Blake]

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

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.  m4 was
originally creating an alternate stack of 16k in size, based on a pure
guess that it would be large enough (since the headers didn't declare
any constant otherwise); but cygwin's sigaltstack() requires an
alternate stack of 64k or larger.

I see a couple of options:

1. see if we can relax cygwin.dll to live with a 16k alternate stack

2. recompile every application that linked against libsigsegv to make
use of cygwin's new constants (at least those applications like m4 that
were using shared gnulib code to guess at the right stack size will now
guess correctly, hand a larger stack to libsigsegv, and libsigsegv can
then just use sigaltstack() as desired)

3. recompile libsigsegv for 32-bit to put in a hack: if the stack size
passed by the caller is < 64k but >= 16k, then fall back to the older
back-door Windows native stack overflow handling.

Option 1 is risky and might not be possible; option 2 will happen
eventually, but option 3 seems like the smoothest way to avoid breaking
things while waiting to reach the point of option 2.  Of course, if we
can get all maintainers to rebuild, then option 3 is wasted effort.

How many applications would need to be rebuilt?  I see:

diffutils [me]
m4 [me]
clisp [Ken Brown]

and nothing else mentioning libsigsegv in 32-bit setup.hints.

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

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

[Corinna Vinschen]

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

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.

> m4 was
> originally creating an alternate stack of 16k in size, based on a pure
> guess that it would be large enough (since the headers didn't declare
> any constant otherwise); but cygwin's sigaltstack() requires an
> alternate stack of 64k or larger.

No, 32K (MINSIGSTKSZ) is sufficient.

> I see a couple of options:
> 
> 1. see if we can relax cygwin.dll to live with a 16k alternate stack

Right now, the bookkeeping at the top of the alternate stack is required
only for a handful of saved registers and what the altstack_wrapper
function needs.  All in all that amounts to 464 bytes on 64 bit and 336
bytes on 32 bit, so there's still plenty of stack, even with a 2K stack,
as is the definition of MINSIGSTKSZ on x86{_64} Linux.

The reason I raised MINSIGSTKSZ to 32K was that sigaltstack is pretty
new, so I was unsure if there might be a good reason to copy the _cygtls
area over to the alternate stack for some reason.  If so, we would have
needed another 12K of the stack for bookkeeping.

MINSIGSTKSZ is defined like this in SUSv4:

 "The value MINSIGSTKSZ is defined to be the minimum stack size for a
  signal handler. In computing an alternate stack size, a program should
  add that amount to its stack requirements to allow for the system
  implementation overhead."

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.

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.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Eric Blake]

[-- 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 --]

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

[Corinna Vinschen]

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

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 #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Corinna Vinschen]

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

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.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [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

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

[Corinna Vinschen]

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

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

Great, thanks for testing!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Ken Brown]

On 7/20/2015 9:03 AM, Ken Brown wrote:
> On 7/20/2015 7:20 AM, Corinna Vinschen wrote:
>> 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.

I've rebuilt clisp on both 32-bit and 64-bit, now using libsigsegv on 
64-bit, and I don't see any regressions.  In particular, it passes the 
test suite.  I don't know enough about clisp to test it further.

Ken

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

[Achim Gratz]

Ken Brown writes:
> I've rebuilt clisp on both 32-bit and 64-bit, now using libsigsegv on
> 64-bit, and I don't see any regressions.  In particular, it passes the
> test suite.  I don't know enough about clisp to test it further.

Does maxima still work with the rebuilt clisp or do I need to rebuild
it, too?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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

[Ken Brown]

On 7/21/2015 4:25 PM, Achim Gratz wrote:
> Ken Brown writes:
>> I've rebuilt clisp on both 32-bit and 64-bit, now using libsigsegv on
>> 64-bit, and I don't see any regressions.  In particular, it passes the
>> test suite.  I don't know enough about clisp to test it further.
>
> Does maxima still work with the rebuilt clisp or do I need to rebuild
> it, too?

You'll have to rebuild it.  Otherwise, you get the following:

$ maxima
/usr/lib/clisp-2.49+/base/lisp: initialization file 
`/usr/lib/maxima/5.36.0/binary-clisp/maxima.mem' was not created by this 
version of CLISP runtime

I don't plan to release the new clisp until cygwin-2.2.0-1 is released, 
in case there are further Cygwin changes that might affect the build.

Ken

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

[Corinna Vinschen]

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

On Jul 21 16:47, Ken Brown wrote:
> On 7/21/2015 4:25 PM, Achim Gratz wrote:
> >Ken Brown writes:
> >>I've rebuilt clisp on both 32-bit and 64-bit, now using libsigsegv on
> >>64-bit, and I don't see any regressions.  In particular, it passes the
> >>test suite.  I don't know enough about clisp to test it further.
> >
> >Does maxima still work with the rebuilt clisp or do I need to rebuild
> >it, too?
> 
> You'll have to rebuild it.  Otherwise, you get the following:
> 
> $ maxima
> /usr/lib/clisp-2.49+/base/lisp: initialization file
> `/usr/lib/maxima/5.36.0/binary-clisp/maxima.mem' was not created by this
> version of CLISP runtime
> 
> I don't plan to release the new clisp until cygwin-2.2.0-1 is released, in
> case there are further Cygwin changes that might affect the build.

I'm not planning any other changes to Cygwin 2.2.0.  Bugfixes only from
now on.  I'm inclined to release 2.2.0-1 this Friday or Monday.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Ken Brown]

On 7/22/2015 4:16 AM, Corinna Vinschen wrote:
> On Jul 21 16:47, Ken Brown wrote:
>> On 7/21/2015 4:25 PM, Achim Gratz wrote:
>>> Ken Brown writes:
>>>> I've rebuilt clisp on both 32-bit and 64-bit, now using libsigsegv on
>>>> 64-bit, and I don't see any regressions.  In particular, it passes the
>>>> test suite.  I don't know enough about clisp to test it further.
>>>
>>> Does maxima still work with the rebuilt clisp or do I need to rebuild
>>> it, too?
>>
>> You'll have to rebuild it.  Otherwise, you get the following:
>>
>> $ maxima
>> /usr/lib/clisp-2.49+/base/lisp: initialization file
>> `/usr/lib/maxima/5.36.0/binary-clisp/maxima.mem' was not created by this
>> version of CLISP runtime
>>
>> I don't plan to release the new clisp until cygwin-2.2.0-1 is released, in
>> case there are further Cygwin changes that might affect the build.
>
> I'm not planning any other changes to Cygwin 2.2.0.  Bugfixes only from
> now on.  I'm inclined to release 2.2.0-1 this Friday or Monday.

In that case there's probably no reason for me to wait, unless Achim 
wants more time for maxima.  Achim, what's your preference?  If you 
want, you can install the new clisp from my repository 
(http://sanibeltranquility.com/cygwin) and use it to rebuild/test 
maxima.  There are instructions at that site.

Ken

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

[Achim Gratz]

Ken Brown writes:
> In that case there's probably no reason for me to wait, unless Achim
> wants more time for maxima.  Achim, what's your preference?  If you
> want, you can install the new clisp from my repository
> (http://sanibeltranquility.com/cygwin) and use it to rebuild/test
> maxima.  There are instructions at that site.

I'll see that I get it done over the weekend using the version in your
private repository.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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

[Achim Gratz]

Ken Brown writes:
> In that case there's probably no reason for me to wait, unless Achim
> wants more time for maxima.  Achim, what's your preference?  If you
> want, you can install the new clisp from my repository
> (http://sanibeltranquility.com/cygwin) and use it to rebuild/test
> maxima.  There are instructions at that site.

I've rebuilt maxima with the new clisp from your site.  I'm ready when
you are, although for practical reasons I'd want to roll things up
together with the Perl update.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Ken Brown]

On 7/26/2015 1:55 PM, Achim Gratz wrote:
> Ken Brown writes:
>> In that case there's probably no reason for me to wait, unless Achim
>> wants more time for maxima.  Achim, what's your preference?  If you
>> want, you can install the new clisp from my repository
>> (http://sanibeltranquility.com/cygwin) and use it to rebuild/test
>> maxima.  There are instructions at that site.
>
> I've rebuilt maxima with the new clisp from your site.  I'm ready when
> you are, although for practical reasons I'd want to roll things up
> together with the Perl update.

That's fine, let's do it with the Perl update.

Ken

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

[Eric Blake]

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

On 07/18/2015 02:11 PM, Corinna Vinschen wrote:

>> m4 was
>> originally creating an alternate stack of 16k in size, based on a pure
>> guess that it would be large enough (since the headers didn't declare
>> any constant otherwise); but cygwin's sigaltstack() requires an
>> alternate stack of 64k or larger.
> 
> No, 32K (MINSIGSTKSZ) is sufficient.
> 
>> I see a couple of options:
>>
>> 1. see if we can relax cygwin.dll to live with a 16k alternate stack
> 

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

I just tested: m4-1.4.17-1 (which uses the 16k alt-stack, compared to
1.4.17-2 using 64k) coupled with the test cygwin 2.2.0-0.1 is once again
able to make use of libsigsegv-2.10-2.  And if I recompile m4 against
cygwin 2.2.0-0.1 headers, I end up with a 32k stack which also works.

That means that so far, I have not found any problems with your new
smaller stack sizing requirements.

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

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

[Corinna Vinschen]

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

On Jul 20 12:19, Eric Blake wrote:
> On 07/18/2015 02:11 PM, Corinna Vinschen wrote:
> 
> >> m4 was
> >> originally creating an alternate stack of 16k in size, based on a pure
> >> guess that it would be large enough (since the headers didn't declare
> >> any constant otherwise); but cygwin's sigaltstack() requires an
> >> alternate stack of 64k or larger.
> > 
> > No, 32K (MINSIGSTKSZ) is sufficient.
> > 
> >> I see a couple of options:
> >>
> >> 1. see if we can relax cygwin.dll to live with a 16k alternate stack
> > 
> 
> > 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.
> 
> I just tested: m4-1.4.17-1 (which uses the 16k alt-stack, compared to
> 1.4.17-2 using 64k) coupled with the test cygwin 2.2.0-0.1 is once again
> able to make use of libsigsegv-2.10-2.  And if I recompile m4 against
> cygwin 2.2.0-0.1 headers, I end up with a 32k stack which also works.
> 
> That means that so far, I have not found any problems with your new
> smaller stack sizing requirements.

Thanks for testing.  That's a good start.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Ken Brown]

On 7/18/2015 2:18 PM, 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.  m4 was
> originally creating an alternate stack of 16k in size, based on a pure
> guess that it would be large enough (since the headers didn't declare
> any constant otherwise); but cygwin's sigaltstack() requires an
> alternate stack of 64k or larger.
>
> I see a couple of options:
>
> 1. see if we can relax cygwin.dll to live with a 16k alternate stack
>
> 2. recompile every application that linked against libsigsegv to make
> use of cygwin's new constants (at least those applications like m4 that
> were using shared gnulib code to guess at the right stack size will now
> guess correctly, hand a larger stack to libsigsegv, and libsigsegv can
> then just use sigaltstack() as desired)
>
> 3. recompile libsigsegv for 32-bit to put in a hack: if the stack size
> passed by the caller is < 64k but >= 16k, then fall back to the older
> back-door Windows native stack overflow handling.
>
> Option 1 is risky and might not be possible; option 2 will happen
> eventually, but option 3 seems like the smoothest way to avoid breaking
> things while waiting to reach the point of option 2.  Of course, if we
> can get all maintainers to rebuild, then option 3 is wasted effort.
>
> How many applications would need to be rebuilt?  I see:
>
> diffutils [me]
> m4 [me]
> clisp [Ken Brown]

I was planning to rebuild 64-bit clisp anyway, to take advantage of the 
new libsigsegv, so I can rebuild on 32-bit also.  But there's no big 
rush, so I'll probably wait for Cygwin 2.2.0 unless someone reports a 
problem before then.

Ken