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:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=dsaH3GQs52cbfgxBuol5cXjBkSHtA05HPMVAa8gb4CddslAJR8ILO BZ+utmd0MydtRTLPsCAR7IUGVf34io2oBun4TLsTlw8EkHyirIHJTOFQQL6vFk4q 5azhdmXThCpbeJ0Fn7lZyo4KZUBzUklHrmNGKDdGrr/CCB+4yHOrxQ= 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:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=HTlhQ/Ao9Xy920l9tsP5FYS2f90=; b=b2Ngcl2aWs8UPvaveYj7rymtUMYc EQnwuANxkVsveyBTHKneyJViyKatB/6HKgCrEsw1nDKk7zuRa2l0J9Yn7xK62kwh 8xVmdmwXG97WOyTAie1DfTtPIvhYRSbBM0QmJ3pafbwoQe7pAixQHV06mpH5gCts rJrblLUAUfA7Zhg= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Date: Fri, 26 Jun 2015 16:14:37 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1 Message-ID: <20150626141437.GV31223@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FiqEyLLt06qkB6ow" Content-Disposition: inline In-Reply-To: <558D3F4C.6090207@cornell.edu> User-Agent: Mutt/1.5.23 (2014-03-12) --FiqEyLLt06qkB6ow Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ken, On Jun 26 08:02, Ken Brown wrote: > On 6/26/2015 7:12 AM, Corinna Vinschen wrote: > >On Jun 22 13:08, Corinna Vinschen wrote: > >>On Jun 21 14:47, Ken Brown wrote: > >>>On 6/20/2015 4:55 PM, Corinna Vinschen wrote: > >>>>- First cut of an implementation to allow signal handlers running on = an > >>>> alternate signal stack. > >>>> > >>>>- New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, S= S_DISABLE, > >>>> MINSIGSTKSZ, SIGSTKSZ. > >>>[...] > >>[...] > >did you have a chance to test this a bit, in the meantime? >=20 > Yes, but I don't have anything definitive to report yet. I tried to test= a > facility in emacs that uses the alternate stack to recover from stack > overflow (of the main stack) under some circumstances. The configure scr= ipt > did detect the alternate stack. >=20 > I then made the stack overflow by defining an elisp function that did an > infinite recursion. emacs still crashed, but the "segmentation fault" > message was printed twice instead of once. I haven't had a chance yet to > investigate further and try to see what's going on. What I hope is that = the > alternate stack functioned correctly but the code was still not able to > recover for some reason. I've appended below the signal handler in case = you > want to see if you think it ought to work on Cygwin. Thank you. I'll try to test this in the next couple of days. One hint and one question: > The signal handler: >=20 > /* 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; >=20 > 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 =3D 16 * 1024 }; > char *beg, *end, *addr; >=20 > beg =3D stack_bottom; > end =3D stack_bottom + stack_direction * rlim.rlim_cur; > if (beg > end) > addr =3D beg, beg =3D end, end =3D addr; > addr =3D (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); > } > } >=20 > /* Otherwise we can't do anything with this. */ > deliver_fatal_thread_signal (sig); > } >=20 > The code to set up the signal handler on the alternate stack: >=20 > static bool > init_sigsegv (void) > { > struct sigaction sa; > stack_t ss; >=20 > stack_direction =3D ((char *) &ss < stack_bottom) ? -1 : 1; >=20 > ss.ss_sp =3D sigsegv_stack; > ss.ss_size =3D sizeof (sigsegv_stack); ^^^^^^^^^^^^^^^^^^^^^^^ What's that size in bytes? > ss.ss_flags =3D 0; > if (sigaltstack (&ss, NULL) < 0) > return 0; >=20 > sigfillset (&sa.sa_mask); > sa.sa_sigaction =3D handle_sigsegv; > sa.sa_flags =3D SA_SIGINFO | SA_ONSTACK | emacs_sigaction_flags (); > return sigaction (SIGSEGV, &sa, NULL) < 0 ? 0 : 1; > } Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --FiqEyLLt06qkB6ow Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVjV5NAAoJEPU2Bp2uRE+gXd4QAJDhrsC8/R8y+nO/hCQUFUVi KfHcD6T88XUrrZw99mj95WHJKV0q6JkU9SWhUkXNW2znSuK8lBzNAt9ssMkHGz8y 6JRi1pxGuvGZoYpWCxceTKD7hXoQBHt0EOEKsVSaLLeLTWxYWg98ozN0VT1Dwcx1 Dux+9oUxtIZs0YodufAnH7f2YUM+96B3iYKlqzjWjnUzpU+wAkf1pod1o33scwOP HAu62PynZbF/V3ZcV8ep5DwtjKclldOq+mEvex6nRrUvnsRW4q4Zox1dycs9PGrm X7p69CiOR1A5QgT4BCM7XOGt4EQGZMyFyfMErBHeAx4u1hPrwv90DF4Jkw1/AJSk sYP4Ng+NDWv6XubQ1c41hrhj3p13EG5iFwjZBSkROQ8RuI7Euw6MAi9aaxZKGgOT dOs+4RKf+KFUmgeFqWVbQijIQSXyHwVk9yGXr/SCHlFZq653tDrlNP4CK7mHziLX RIgdNJ3e+bRQgVOElUHXg1Za7Ta9KanoWA7nyzGQcO9pF1buKI02bbChA4ZQ2BeZ feqfgPYgBge7B2DWlZmdS+U4C/mox1IEr7Lvv5H0vzbSlAHhfFeuyb2+sYJu8K3Q GRaMzZf6srlsX1geA+bXC7GojEIVuoGfNBKSkhaMaB037QAkEH8NBE/W/m9Iveg/ 0L+/uK44Bk+9ilGEJO/Z =xrtW -----END PGP SIGNATURE----- --FiqEyLLt06qkB6ow--