[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4

Mon Jul 6 16:34:00 GMT 2015

On Jul 6 11:54, Ken Brown wrote:
> On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
> >Does emacs call setrlimit by any chance?
>> Yes, that's the problem. The initialization code contains essentially the
> following:
>> if (!getrlimit (RLIMIT_STACK, &rlim))
> {
> long newlim;
> /* Approximate the amount regex.c needs per unit of re_max_failures. */
> int ratio = 20 * sizeof (char *);
> /* Then add 33% to cover the size of the smaller stacks that regex.c
> 	 successively allocates and discards, on its way to the maximum. */
> ratio += ratio / 3;
> /* Add in some extra to cover
> 	 what we're likely to use for other reasons. */
> newlim = re_max_failures * ratio + 200000;
> if (newlim > rlim.rlim_max)
> 	{
> 	 newlim = rlim.rlim_max;
> 	 /* Don't let regex.c overflow the stack we have. */
> 	 re_max_failures = (newlim - 200000) / ratio;
> 	}
> if (rlim.rlim_cur < newlim)
> 	rlim.rlim_cur = newlim;
>> setrlimit (RLIMIT_STACK, &rlim);
> }

Ok.
> If I disable that code, the problem goes away: rlim_cur is set to the
> expected 0x7fd000 in handle_sigsegv, and emacs recovers from the stack
> overflow.

:)))

> I think I probably should disable that code on Cygwin anyway, because
> there's simply no need for it. Some time ago I discovered that the default
> 2MB stack size was not big enough for emacs on Cygwin, and I made emacs use
> 8MB instead. So there's no need to enlarge it further.

Yes, that probably makes sense. The computed expression above has
another problem on Windows: The stacksize is always a multiple of 64K
due to the dreaded allocation granularity.
> >Btw., *if* emacs calls setrlimit and then expects getrlimit to return
> >the *actual* size of the stack, rather than expecting that rlim_cur is
> >just a default value when setting up stacks, it's really doing something
> >borderline.
> >
> >There's simply *no* guarantee that a stack can be extended to this size.
> >Any mmap() call could disallow growing the stack beyond its initial
> >size. Worse, on Linux you can even mmap so that the stack doesn't
> >grow to the supposed initial maximum size at all. The reason is that
> >Linux doesn't know the concept of "reserved" virtual memory, but the
> >stack is initially not commited in full either.
> >
> >If you want to know how big your current stack *actually* is, you can
> >utilize pthread_getattr_np on Linux and Cygwin, like this:
> >
> >#include <pthread.h>
> >
> > static void
> > handle_sigsegv (int sig, siginfo_t *siginfo, void *arg)
> > {
> > pthread_attr_t attr;
> > size_t stacksize;
> >
> > if (!pthread_getattr_np (pthread_self (), &attr)
> >	&& !pthread_attr_getstacksize (&attr, &stacksize))
> > {
> >	beg = stack_bottom;
> >	end = stack_bottom + stack_direction * stacksize;
> >
> >	[...]
> >
> >Unfortunately this is non-portable as well, as the trailing _np denotes,
> >but at least there *is* a reliable method on Linux and Cygwin...
>> Thanks. That fixes the problem too, even with the call to setrlimit left
> in. I'll report this to the emacs developers.

Excellent, thanks for testing this!
Corinna
-- 
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150706/facb193d/attachment.sig>