Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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
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
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
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 pgpI1MF2pCElh.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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
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
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
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
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 pgp4yqeYIAeE7.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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
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 signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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 pgp4SJEgERCIF.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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 pgpq5HTotVt_c.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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 pgp9yXOnkqw0i.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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 signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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
pgpsP0j1mqqWk.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2
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 signature.asc Description: OpenPGP digital signature
