delorie.com/archives/browse.cgi | search |
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=ZAlLBv0GW16G8Aw7lgEcbUmH/OF+80bQ+xL/fQ4Dmrg90vUuiv3D0 | |
PcHNoxOAN5c1Ldx9LIRtYTvtivmu/3g+AMLrQ2Bn84aQoSDeYgIAH7icUPTJ3+QQ | |
3Y6yu4386pY1rJXlxFYutAtO3WbojrHTZUvMCkT/hsC36MgjEtYkPk= | |
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=6WNEPsLYWwakBGd8BadjWOGJ/cg=; b=UtJSobVwUjByvvHNCLFJHpIKKp1c | |
PtD085S3+SC1PepEliwvwWv8L9bZsjGaynhL53oCofvmDQ/Z2evzGGgG2gYHdSZg | |
Qupj/gzweJZPLRwpa4ZX7I8Dcws/Uy/s35E2ZvJQbSuI5g0p9ISY4DXk6sQDjyUW | |
i8RKZot6B9uRE+Q= | |
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=-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: | Mon, 6 Jul 2015 16:45:55 +0200 |
From: | Corinna Vinschen <corinna-cygwin AT cygwin DOT com> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4 |
Message-ID: | <20150706144555.GR2918@calimero.vinschen.de> |
Reply-To: | cygwin AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
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> <559A7F74 DOT 1000402 AT cornell DOT edu> |
MIME-Version: | 1.0 |
In-Reply-To: | <559A7F74.1000402@cornell.edu> |
User-Agent: | Mutt/1.5.23 (2014-03-12) |
--tzjrJU3+iJ6c5SNx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ken, On Jul 6 09:15, Ken Brown wrote: > Hi Corinna, >=20 > 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? >=20 > I'm on W7 64-bit. The problem seems to be that rlim_cur is too big. >=20 > $ peflags -x ./emacs > ./emacs: stack reserve size : 8388608 (0x800000) bytes >=20 > (gdb) p beg > $3 =3D 0x82ca27 "" > (gdb) p/x rlim.rlim_cur > $2 =3D 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) =3D=3D 0x7fd000. > So there's overflow when end is computed: >=20 > (gdb) p end > $4 =3D 0xfffffffffffdbba7 <error: Cannot access memory at address 0xfffff= ffffffdbba7> >=20 > This doesn't happen when I run your testcase with the same 8MB stack size: >=20 > $ peflags -x0x800000 ./sigalt.exe > ./sigalt.exe: stack reserve size : 8388608 (0x800000) bytes >=20 > (gdb) p beg > $1 =3D 0x82cabb "" > (gdb) p/x rlim.rlim_cur > $2 =3D 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 =3D stack_bottom; end =3D 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 --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --tzjrJU3+iJ6c5SNx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVmpSjAAoJEPU2Bp2uRE+gDYUP/1diHO9swsMalbj5SDSzlIzl RY/8590ks2pb0AFHrra/mdjTY/rAYeEJkp2PefGioGZ/faOIBZPpf860t8LyixaR OraQYKoiaPYA+g+rH477U7+q/Hf0kbSzG2kd5wXumdIcIkqNfe+eErMCP3G40kcN Wz3TUQm7LoE791xzPF8fye6upo4cKzt2zX7i+pjXIhqPilX4KJEcI+LHypH9mxOj AS+YUu8z+YX+tl9Wp2QRnMPYDPQiy3e+yvPROGDxSK/fUs6u9TDKz3+KbQJkdNWV PIVZY6uOjyfWGHZLPaak5Tsbbmqpl1u1tDKWaTjzIAdqZUACZdl+kA6UvQAXdL3c 8Sc7aBrpyvMJjOJRfyMOFNWSO5RnY8mFYnLRqsU+K9ad4HpGMMdjKI17g0o3jRam ewlkvw7u9A0FF6+KpzaOXPHhLNYapBPL4Qsq0FeYT8OcrUyA32a0IMG2SsrStOKw Q2S3BoFSi6CXMaIm3+2hhIAgxJDJH2p3B/1zOljZhmagC3lMfu87jLYA8hM9KVYf PkUNPtA1GtJ+TAz/2pfPoB7hrcUwZUgywfXoKmUcVdSsG93+Q9lSaBzni96rwDC/ Br5U8Q9jV4S7CvHk+HW1oeiVs+DXUIuVQHkaGgbX21xn+7HiV5J6zrPtursQmNVc /KtE7caj03ELWVGyt/Vh =3uAc -----END PGP SIGNATURE----- --tzjrJU3+iJ6c5SNx--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |