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=Q0GbMjpBk8FLMfdmdiTaFdsRIrPmE81765mc8AY5l1s
	k4bNZY5r654Llwx3HgbUuuMIaUDtxb6WZGMSsi/zZ2DWnQMBKJu0EXIzJoaRmJUq
	FA4zK5GyGRhKNn8ZjN4Lio81v/RLFINzRhPSJI40TH9twg0Cjc/B/xMtAz02knD8
	=
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=G/D5fbmyMynz7BmXTtUAGUjKhW4=; b=RHaZIZhChguA1c0q4
	gV2cgfPeUvfX26itDVWVWjpT9fcTJtVhoWFu807OIP07cwGqLvabTc5koINZrzla
	WagOrNsdKQN7Km6nsuvoFETjQzDBlwFov2bXj3V2XXwTrtz62IWBgI69ymRjHJ8I
	cteoNpaekX4YRp4Jacjg9JLFwY=
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=-2.5 required=5.0 tests=AWL,BAYES_00,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: <558D8409.2000400@cornell.edu>
Date: Fri, 26 Jun 2015 12:55:37 -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.1
References: <announce DOT 20150620205512 DOT GA28301 AT calimero DOT vinschen DOT de> <558706D5 DOT 1020508 AT cornell DOT edu> <20150622110835 DOT GE28301 AT calimero DOT vinschen DOT de> <20150626111249 DOT GS31223 AT calimero DOT vinschen DOT de> <558D3F4C DOT 6090207 AT cornell DOT edu> <20150626141437 DOT GV31223 AT calimero DOT vinschen DOT de> <558D62D7 DOT 8010709 AT cornell DOT edu> <20150626153647 DOT GX31223 AT calimero DOT vinschen DOT de>
In-Reply-To: <20150626153647.GX31223@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Hi Corinna,

On 6/26/2015 11:36 AM, Corinna Vinschen wrote:
> Hi Ken,
>
> On Jun 26 10:33, Ken Brown wrote:
>> On 6/26/2015 10:14 AM, Corinna Vinschen wrote:
>>> On Jun 26 08:02, Ken Brown wrote:
>>>> On 6/26/2015 7:12 AM, Corinna Vinschen wrote:
>>> Thank you.  I'll try to test this in the next couple of days.  One hint
>>> and one question:
>>>
>>>> The signal handler:
>>>>
>>>> /* Attempt to recover from SIGSEGV caused by C stack overflow.  */
>>>> static void
>>>> handle_sigsegv (int sig, siginfo_t *siginfo, void *arg)
>>>> {
>>>>    /* Hard GC error may lead to stack overflow caused by
>>>>       too nested calls to mark_object.  No way to survive.  */
>>>>    if (!gc_in_progress)
>>>>      {
>>>>        struct rlimit rlim;
>>>>
>>>>        if (!getrlimit (RLIMIT_STACK, &rlim))
>>>
>>> This getrlimit probably won't work as desired.  I just had a quick look
>>> how this request is handled.  It will return the size of the alternate
>>> stack while running the signal handler, rather than the size of the
>>> initial thread's stack as required by POSIX.  This definitely needs
>>> fixing.
>>>
>>>> 	{
>>>> 	  enum { STACK_DANGER_ZONE = 16 * 1024 };
>>>> 	  char *beg, *end, *addr;
>>>>
>>>> 	  beg = stack_bottom;
>>>> 	  end = stack_bottom + stack_direction * rlim.rlim_cur;
>>>> 	  if (beg > end)
>>>> 	    addr = beg, beg = end, end = addr;
>>>> 	  addr = (char *) siginfo->si_addr;
>>>> 	  /* If we're somewhere on stack and too close to
>>>> 	     one of its boundaries, most likely this is it.  */
>>>> 	  if (beg < addr && addr < end
>>>> 	      && (addr - beg < STACK_DANGER_ZONE
>>>> 		  || end - addr < STACK_DANGER_ZONE))
>>>> 	    siglongjmp (return_to_command_loop, 1);
>>>> 	}
>>>>      }
>>>>
>>>>    /* Otherwise we can't do anything with this.  */
>>>>    deliver_fatal_thread_signal (sig);
>>>> }
>>>>
>>>> The code to set up the signal handler on the alternate stack:
>>>>
>>>> static bool
>>>> init_sigsegv (void)
>>>> {
>>>>    struct sigaction sa;
>>>>    stack_t ss;
>>>>
>>>>    stack_direction = ((char *) &ss < stack_bottom) ? -1 : 1;
>>>>
>>>>    ss.ss_sp = sigsegv_stack;
>>>>    ss.ss_size = sizeof (sigsegv_stack);
>>>                   ^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>> What's that size in bytes?
>>
>> SIGSTKSZ
>
> Thanks.  Another question:  How does emacs compute stack_bottom?

Very near the beginning of main() it does the following:

   char stack_bottom_variable;
[...]
   /* Record (approximately) where the stack begins.  */
   stack_bottom = &stack_bottom_variable;

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