This is the mail archive of the cygwin 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] TEST RELEASE: Cygwin 2.1.0-0.4


Hi Ken,

On Jul  6 09:15, Ken Brown wrote:
> Hi Corinna,
> 
> On 7/6/2015 6:01 AM, Corinna Vinschen wrote:
> >On Jul  5 22:15, Ken Brown wrote:
> >
> >I have no explanation for this.  What OS?  What does rlim_cur contain?
> >What does peflags -x print for this executable?
> 
> I'm on W7 64-bit.  The problem seems to be that rlim_cur is too big.
> 
> $ peflags -x ./emacs
> ./emacs: stack reserve size      : 8388608 (0x800000) bytes
> 
> (gdb) p beg
> $3 = 0x82ca27 ""
> (gdb) p/x rlim.rlim_cur
> $2 = 0x850e80

Does emacs call setrlimit by any chance?  Otherwise, rlim_cur should be
set to

  0x800000 - 0x1000 (4K dead zone) - 0x2000 (8K guard page on W7 64)
  == 0x7fd000.

> So there's overflow when end is computed:
> 
> (gdb) p end
> $4 = 0xfffffffffffdbba7 <error: Cannot access memory at address 0xfffffffffffdbba7>
> 
> This doesn't happen when I run your testcase with the same 8MB stack size:
> 
> $ peflags -x0x800000 ./sigalt.exe
> ./sigalt.exe: stack reserve size      : 8388608 (0x800000) bytes
> 
> (gdb) p beg
> $1 = 0x82cabb ""
> (gdb) p/x rlim.rlim_cur
> $2 = 0x7fd000

... like this.

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


Corinna

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

Attachment: pgpRHnJ0ZQAak.pgp
Description: PGP signature


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