This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]