X-Recipient: archive-cygwin AT delorie DOT com
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=OlJbqgKICaHiarFFcqef/c8/XV5zu6h83kn2II4rDsT
	RG1oijGYD0kV0z0n40aNZDTQ6m/Sd8xW1Duki+YHJk2h/i78yirrg2t+KsiOTReh
	/eVAjj6hp129BnYy7B4W6OhfXwbf1rFZ1xSZga71uXOenvTKG1teBhv8sXBZQ8Ss
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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;
	 s=default; bh=6vqAQvebtip84WkGPaAXShhz1ZI=; b=ybul9KJnpFw9kb4mQ
	m5SHGWE7Xm1On//rfp/K9Tq6ZvFNLsJbBabLz0zXK6bIS3LpjojXmB0kih9QgYnY
	x/dNN5cCfSZN9AOozdAK/nNIGV5O3Xi23NiCJ7/AhLobfGDvV9PlfGZOrQmjK9xK
	Qq6ygMRusjjVk0CnvSYlr7e6AM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: limerock03.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Message-ID: <5599E4C5.1010109@cornell.edu>
Date: Sun, 05 Jul 2015 22:15:33 -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>
In-Reply-To: <announce.20150705213417.GH2918@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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:

$ gdb ./emacs.exe
[...]
(gdb) b handle_sigsegv
Breakpoint 3 at 0x1005657b3: file ../../master/src/sysdep.c, line 1643.
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/64build/src/emacs.exe -Q
[At this point I force stack overflow.]

Program received signal SIGSEGV, Segmentation fault.
0x000000010053b08b in builtin_lisp_symbol (index=290)
     at ../../master/src/lisp.h:1069
1069      return make_lisp_symbol (lispsym + index);
(gdb) c
Continuing.

Breakpoint 3, handle_sigsegv (sig=11,
     siginfo=0x100a3e190 <sigsegv_stack+65232>, arg=0x82de50)
     at ../../master/src/sysdep.c:1643
1643      if (!gc_in_progress)
(gdb) l
1638    static void
1639    handle_sigsegv (int sig, siginfo_t *siginfo, void *arg)
1640    {
1641      /* Hard GC error may lead to stack overflow caused by
1642         too nested calls to mark_object.  No way to survive.  */
1643      if (!gc_in_progress)
1644        {
1645          struct rlimit rlim;
1646
1647          if (!getrlimit (RLIMIT_STACK, &rlim))
(gdb)
1648            {
1649    #ifdef CYGWIN
1650              enum { STACK_DANGER_ZONE = 32 * 1024 };
1651    #else
1652              enum { STACK_DANGER_ZONE = 16 * 1024 };
1653    #endif
1654              char *beg, *end, *addr;
1655
1656              beg = stack_bottom;
1657              end = stack_bottom + stack_direction * rlim.rlim_cur;
(gdb)
1658              if (beg > end)
1659                addr = beg, beg = end, end = addr;
1660              addr = (char *) siginfo->si_addr;
1661              /* If we're somewhere on stack and too close to
1662                 one of its boundaries, most likely this is it.  */
1663              if (beg < addr && addr < end
1664                  && (addr - beg < STACK_DANGER_ZONE
1665                      || end - addr < STACK_DANGER_ZONE))
1666                siglongjmp (return_to_command_loop, 1);
1667            }
(gdb) n
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 ""

Note that addr < beg, so we never reach the siglongjmp.

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