DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=yH9TqqIWJcT3X27NukXEpQRg0nUWlyzHMT7dkf4g9zx
	fALS7I8NqrEyyI2drVjjw9/56G6pUzORmOB/0OO8Fasw+s06j35R6IfVBklYCFGT
	D3YS90aVylhg9KufjY4q2UnubajT6n2dYIbfluES6+bysPIEDGm9fJLAmlfEnvoQ
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <559A7F74.1000402@cornell.edu>
Date: Mon, 06 Jul 2015 09:15:32 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4
References: <announce DOT 20150705213417 DOT GH2918 AT calimero DOT vinschen DOT de> <5599E4C5 DOT 1010109 AT cornell DOT edu> <20150706100158 DOT GJ2918 AT calimero DOT vinschen DOT de>
In-Reply-To: <20150706100158.GJ2918@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Corinna,

On 7/6/2015 6:01 AM, Corinna Vinschen wrote:
> Hi Ken,
>
>
> thanks for further testing this.
>
>
> On Jul  5 22:15, Ken Brown wrote:
>> On 7/5/2015 5:34 PM, Corinna Vinschen wrote:
>>> This test release needs some good testing!
>>
>> I repeated the emacs experiment discussed in the "[ANNOUNCEMENT] TEST
>> RELEASE: Cygwin 2.1.0-0.1" thread.  In the 32-bit case, the results were
>> more-or-less the same as before: I forced a stack overflow, emacs recovered,
>> I tried to continue working, there was a second SIGSEGV, and handle_sigsegv
>> bailed out because garbage collection was in progress.  This time I was
>> unable to prevent the second SIGSEGV by resetting max-specpdl-size and
>> max-lisp-eval-depth.  I'm not sure what caused the second SIGSEGV, but it
>> might have nothing to do with Cygwin.
>>
>> In the 64-bit case, however, the recovery from stack overflow never happened
>> (i.e., the program never reached the siglongjmp).  Here's a gdb session:
>> [...]
>> 1647          if (!getrlimit (RLIMIT_STACK, &rlim))
>> (gdb)
>> 1656              beg = stack_bottom;
>> (gdb)
>> 1657              end = stack_bottom + stack_direction * rlim.rlim_cur;
>> (gdb)
>> 1658              if (beg > end)
>> (gdb)
>> 1660              addr = (char *) siginfo->si_addr;
>> (gdb)
>> 1663              if (beg < addr && addr < end
>> (gdb) p beg
>> $1 = 0x82ca27 ""
>> (gdb) p addr
>> $2 = 0x33ff8 ""
>
> I can't reproduce this.  It works fine for me.  For reference I attached
> my simplified testcase again.   It's basically the emacs SIGSEGV setup,
> main triggers the stack overflow, the handler tries to write a file for
> testing if that works from the handler, then it siglongjmps.  The main
> function tests if it can still fork, and then it repeats the action to
> test if we're back to normal in terms of signal handling.
>
> If it works (and it does for me) the output looks like this:
>
>    $ ./sigalt
>    command loop 1 before crash
>    command loop 1 after crash
>    In child
>    In parent
>    command loop 2 before crash
>    command loop 2 after crash
>    In child
>    In parent
>
> On W8.1 for a standard GCC build of this testcase I get:
>
>    (gdb) p beg
>    $1 = 0x40ac3 <error: Cannot access memory at address 0x40ac3>
>    (gdb) p addr
>    $2 = 0x43848 <error: Cannot access memory at address 0x43848>
>    (gdb) p end
>    $3 = 0x23cac3 ""
>    (gdb) p/x rlim.rlim_cur
>    $5 = 0x1fc000
>
> Check default stacksize:
>
>    )$ peflags -x ./sigalt
>    ./sigalt: stack reserve size      : 2097152 (0x200000) bytes
>
>    0x200000 - dead zone 4K - default W8.1 64 bit guardpagesize 3 * 4K ==
>    0x1fc000, the value rlim.rlim_cur returns.  Looks good to me.
>
> On W8.1 32 bit under WOW:
>
>    (gdb) p beg
>    $1 = 0x8fc33 ""
>    (gdb) p addr
>    $2 = 0x92d5c <error: Cannot access memory at address 0x92d5c>
>    (gdb) p end
>    $3 = 0x28cc33 ""
>    (gdb) p/x rlim.rlim_cur
>    $4 = 0x1fd000
>
>    $ peflags -x ./sigalt
>    ./sigalt: stack reserve size      : 2097152 (0x200000) bytes
>
>    0x200000 - dead zone 4K - default W8.1 32 bit guardpagesize 2 * 4K ==
>    0x1fd000.
>
> On W7 32 bit native:
>
> (gdb) p beg
> $1 = 0x2ec43 "\376\356..."
> (gdb) p addr
> $2 = 0x32d6c ""
> (gdb) p end
> $3 = 0x22cc43 ""
> (gdb) p rlim.rlim_cur
> $4 = 2088960
> (gdb) p/x rlim.rlim_cur
> $5 = 0x1fe000
>
>    $ peflags -x ./sigalt
>    ./sigalt: stack reserve size      : 2097152 (0x200000) bytes
>
>    0x200000 - dead zone 4K - default W7 32 bit guardpagesize 1 * 4K ==
>    0x1fe000.
>
>> Note that addr < beg, so we never reach the siglongjmp.
>
> 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

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
(gdb) p end
$3 = 0x2fabb

> And last but not least, what is emacs doing there?  The stack should be
> pretty much in a good shape when it's back to the main loop.  The stack
> is fully commited and has the default number of guardpages at the bottom,
> as it is just short of the stack overflow.
>
> For debugging purposes I also added a global variable called "tib" and a
> memory info struct called "m" to the testcase which are initialized
> right at the start of main.  tib points to the start of the TEB (Thread
> Environment Block, a Windows per-thread bookkeeping structure) of the
> main thread.  If you expand it right after it's fetched, you get
> something along these lines:
>
>    (gdb) p *tib
>    $2 = {ExceptionList = 0x22cd78, StackBase = 0x230000, StackLimit = 0x20c000,
>      SubSystemTib = 0x0, {FiberData = 0x1e00, Version = 7680},
>      ArbitraryUserPointer = 0x0, Self = 0x7ffdf000}
>
> Note the values of StackBase and StackLimit and compare with your beg and
> end values.  StackBase is the upper limit of the stack.  It grows downward
> from there.  StackLimit is the lowest address as yet commited.  It's not much
> yet as you can see, 0x230000-0x20c000 == 0x24000 == 144K.  Since Cygwin
> executables have a default stack of 2 Megs, the allocation base of the stack
> is probably at 0x30000.  This can be checked by looking at m:
>
>    (gdb) p m
>    $1 = {BaseAddress = 0x22c000, AllocationBase = 0x30000, AllocationProtect = 4,
>      RegionSize = 16384, State = 4096, Protect = 4, Type = 131072}
>
> See the value of AllocationBase.
>
> When you hit the breakpoint in handle_sigsegv, the output of tib should
> look like this:
>
>    (gdb) p *tib
>    $2 = {ExceptionList = 0x22cd78, StackBase = 0x230000, StackLimit = 0x32000,
>      SubSystemTib = 0x0, {FiberData = 0x1e00, Version = 7680},
>      ArbitraryUserPointer = 0x0, Self = 0x7ffdf000}
>
> Observe the value of StackLimit.  For this output I ran the testcase on
> W7 32 bit.  It has a default guardpage of 4K.  The new wrapper I wrote
> in Cygwin restored the stack to its state rifght before the stack overflow
> occured:
>
>    - At 0x30000 we have the 4K dead zone, which is always only reserved,
>      never commited.
>
>    - At 0x31000 the 4K guard page starts.
>
>    - Thus the StackLimit (the start of the commited region of the stack)
>      starts at 0x32000.
>
> You can utilize tib and m for testing in emacs as well.  Just do this:
>
>    #include <windows.h>
>
>    NT_TIB *tib;
>    MEMORY_BASIC_INFORMATION m;
>
>    [...]
>
>    in main:
>
>    /* Record (approximately) where the stack begins.  */
>    stack_bottom = &stack_bottom_variable;
>    tib = (NT_TIB *) __readfsdword(PcTeb);
>    VirtualQuery (stack_bottom, &m, sizeof m);

I'll try this next and report back.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple