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:message-id:date:from:mime-version:to:subject | |
:references:in-reply-to:content-type:content-transfer-encoding; | |
q=dns; s=default; b=Gsg40SZ/9GU0HE7qjgvRJlou+CAJ6RLDnIa7cxnyZe9 | |
rDrPjM0W41xmMwU4nK3UoNLIPykOyt2hZ0PAQQAhs6z270xHj8PXhhGrlAChMLE3 | |
pFaP7sk6e0n3IgHruLLFMfndAlAZfwX2fPS4XMJPYyBIcoBPTkVaL+kfHL5LlcG0 | |
= | |
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=dDLvMt9Lri2Hb9pl0x+PfdDbfiY=; b=klYohV9ORfs/eA2w/ | |
E4X3XIV0myoIpNtdHHV859363gPgjtEHAeDqJdhlhgNi36mdawLiqP7PkKtS+yy7 | |
sq3d0K2r+Z4/+fETaVt8hqdrlQOsEM7yylPnib+dgKF6G1BqOA0uV6OhSwjzBed9 | |
1YwDsIvtW9wyzkMdabLzO2xjVk= | |
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 |
X-Spam-SWARE-Status: | No, score=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RP_MATCHES_RCVD,SPF_NEUTRAL autolearn=ham version=3.3.2 |
Message-ID: | <5211F83A.30901@cs.utoronto.ca> |
Date: | Mon, 19 Aug 2013 06:49:30 -0400 |
From: | Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca> |
User-Agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 |
MIME-Version: | 1.0 |
To: | cygwin AT cygwin DOT com |
Subject: | Re: Stack size on 64-bit Cygwin |
References: | <520E905A DOT 409 AT cornell DOT edu> <20130819093242 DOT GB18757 AT calimero DOT vinschen DOT de> |
In-Reply-To: | <20130819093242.GB18757@calimero.vinschen.de> |
On 19/08/2013 5:32 AM, Corinna Vinschen wrote: > On Aug 16 16:49, Ken Brown wrote: >> The problem that has been discussed at length in the thread "64-bit >> emacs crashes a lot" appears to have been solved on the emacs-devel >> list. (I say "appears to" because I'm waiting for Ryan to confirm >> this.) The problem went away for me when I built emacs with >> 'LDFLAGS=-Wl,--stack,4194304'. I'm wondering if it's just that >> emacs needs an unusually big stack or if the default stack size on >> 64-bit Cygwin should be increased for all applications. >> >> I noticed that ulimit -s gives 2025 on both 32-bit Cygwin and 64-bit >> Cygwin. Shouldn't 64-bit applications need a larger stack than >> 32-bit applications in general? > From my POV, if you have a stack-active application, just add the > aforementioned --stack linker option, or call peflags -x after the > build. The latter can be done any time FYI, I just tried upping the stack size on /usr/bin/emacs-nox, but it still crashes. Most likely because the damage was already done during bootstrap, when it has much larger memory requirements than normal. Still no crashes so far in the version I linked with --stack, though. One thing I don't understand, though: shouldn't a stack overflow normally manifest as a seg fault when trying to access the invalid addresses, rather than silent memory corruption? However, /proc/pid/maps for emacs shows: > 00010000-00020000 rw-s 00000000 0000:0000 0 [win > heap 1 default shared] > 00020000-00030000 rw-s 00000000 0000:0000 0 [win > heap 2 default shared] > 00030000-001E4000 ===p 00000000 0000:0000 0 [stack (tid 4896)] > 001E4000-001E6000 rw-g 001B4000 0000:0000 0 [stack (tid 4896)] > 001E6000-00230000 rw-p 001B6000 0000:0000 0 [stack (tid 4896)] GDB reports that thread 4896 is the main thread... so I guess Windows doesn't reserve a red zone around its stack, but instead chooses to place the main thread stack right next to the fully-mapped global shared heap to maximize the potential for Fun? Ryan -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |