From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87524 invoked by alias); 20 Jul 2015 13:03:15 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 87511 invoked by uid 89); 20 Jul 2015 13:03:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: limerock01.mail.cornell.edu Received: from limerock01.mail.cornell.edu (HELO limerock01.mail.cornell.edu) (128.84.13.241) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Jul 2015 13:03:14 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id t6KD3BR8002931 for ; Mon, 20 Jul 2015 09:03:12 -0400 Received: from [192.168.0.32] (d173-238-139-6.home4.cgocable.net [173.238.139.6]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id t6KD3BIQ001856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Jul 2015 09:03:11 -0400 Subject: Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2 To: cygwin-apps@cygwin.com References: <55AA9882.1030407@redhat.com> <20150718201106.GE3864@calimero.vinschen.de> <55AAB9F3.3070505@redhat.com> <20150719083756.GB19825@calimero.vinschen.de> <20150720112049.GP3864@calimero.vinschen.de> From: Ken Brown Message-ID: <55ACF192.6080701@cornell.edu> Date: Mon, 20 Jul 2015 13:03:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150720112049.GP3864@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00134.txt.bz2 On 7/20/2015 7:20 AM, Corinna Vinschen wrote: > On Jul 19 10:37, Corinna Vinschen wrote: >> On Jul 18 14:41, Eric Blake wrote: >>> On 07/18/2015 02:11 PM, Corinna Vinschen wrote: >>>> OTOH, calling certain Cygwin functions might require lots of stack. >>>> E.g. open/read/write/close requires more than 2K stack, so MINSIGSTKSZ >>>> shouldn't be too small. >>>> >>>> So, what about MINSIGSTKSZ == 8192 and SIGSTKSZ == 32768? >>>> >>>> Or MINSIGSTKSZ == 16384 and SIGSTKSZ == 65536? >>>> >>>> That could go into Cygwin 2.2.0 which I could release next week. >>> >>> Might help, but feels a little unclean. As I said, old clients of >>> libsigsegv were using the fallback definition of 16k; setting >>> MINSIGSTKSZ to 16k would let the sigaltstack() succeed where it is now >>> failing, but if cygwin ever consumes all 16k rather than the current 400 >>> or so bytes, that leaves nothing for the application (normally, an >>> application only expects to use SIGSTKSZ - MINSIGSTKSZ for its own use, >>> if it uses the system-recommended sizing). >> >> Cygwin shouldn't really consume 16K stack by itself when called from the >> application. Large buffers should use the tmp_pathbuf facility throughout. >> >> But there are still functions using big stack buffers. I mention them >> here for bookkeeping as much as for information and discussion: >> >> - Debugging code in dcrt0.cc, initial_env() uses 96K stack on process >> startup. Usually disabled. Non-critical. >> >> - dll_list::alloc, called during DLL initialization uses 64K stack. >> Calling dlopen from the alternate stack would be fatal. The buffer >> is used in code called under Windows loader lock conditions, so this >> could be converted to a static buffer. >> >> - A function called error_start_init uses 32K of stack and is called >> if the env var CYGWIN is set to "error_init:...". That's very unlikely >> from a SEGV handler. Not nice, but probably non-critical. >> >> - pinfo::status_exit is called when a process exits due to a signal >> from Windows. This usually shouldn't happen inside the signal >> handler, but it might. pinfo::status_exit uses a 32K buffer. >> >> - Stracing a process ends up using >48K of stack. >> >> That means even the current 32K are not quite sufficient, though, only >> in unlikely border cases, apparently. >> >> Anyway, I plan to change this in the next few days. Given this, I'll >> set MINSIGSTKSZ to 8K and SIGSTKSZ to 32K in 2.2. > > I uploaded snapshots as well as a 2.2.0-0.1 test release. Please > give it a try. Everything is fine as far as emacs is concerned. I'll rebuild clisp and test it later today. Ken