From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64100 invoked by alias); 2 Jul 2015 19:25:54 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 64088 invoked by uid 89); 2 Jul 2015 19:25:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,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; Thu, 02 Jul 2015 19:25:50 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id t62JPlU8028488 for ; Thu, 2 Jul 2015 15:25:48 -0400 Received: from [192.168.1.4] (cpe-67-249-176-138.twcny.res.rr.com [67.249.176.138]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id t62JPk1F009397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 2 Jul 2015 15:25:47 -0400 Message-ID: <55959036.8070300@cornell.edu> Date: Thu, 02 Jul 2015 19:25:00 -0000 From: Ken Brown 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@cygwin.com Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1 References: <20150626200512.GA30636@calimero.vinschen.de> <558DD1F3.4010301@cornell.edu> <20150627145259.GB23036@calimero.vinschen.de> <20150630195547.GG2918@calimero.vinschen.de> <5592F86E.8070803@cornell.edu> <20150701104748.GH2918@calimero.vinschen.de> <20150701135749.GN2918@calimero.vinschen.de> <559449AF.9010804@cornell.edu> <55949D9A.7060900@cornell.edu> <20150702121301.GA25423@calimero.vinschen.de> <20150702122047.GS2918@calimero.vinschen.de> In-Reply-To: <20150702122047.GS2918@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/msg00021.txt.bz2 On 7/2/2015 8:20 AM, Corinna Vinschen wrote: > On Jul 2 14:13, Corinna Vinschen wrote: >> On Jul 1 22:10, Ken Brown wrote: >>> I may have spoken too soon. As I repeat the experiment on a different >>> computer, with a build from a slightly different snapshot of the emacs >>> trunk, emacs crashes when I type 'C-x d' with the following stack dump: >>> >>> Stack trace: >>> Frame Function Args >>> 00100A3E240 00180071CC3 (00000829630, 000008296D0, 00000000000, 0000082CE00) >>> 00030000002 001800732BE (00000000000, 00000000002, 00100A48C80, 00000000002) >>> 00000000000 00000006B40 (00000000002, 00100A48C80, 00000000002, 00100A48768) >>> 00000000000 21000000003 (00000000002, 00100A48C80, 00000000002, 00100A48768) >>> End of stack trace >>> >>> $ addr2line 00180071CC3 -e /usr/lib/debug/usr/bin/cygwin1.dbg >>> /usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exception.h:175 >>> >>> $ addr2line 001800732BE -e /usr/lib/debug/usr/bin/cygwin1.dbg >>> /usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exceptions.cc:1639 >> >> That points to a crash while setting up the alternate stack. This is >> always a possibility because, in contrast to the kernel signal handler >> in a real POSIX system, the Cygwin exception handler is still running on >> the stack which triggered the crash up to the point where we call the >> signal handler function. Dependent on how the stack overflow occured, >> this additional stack usage may be enough to kill the process for good. >> >> Out of curiosity, can you add this to the init_sigsegv() function: >> >> #include >> [...] >> init_sigsegv (void) >> { >> [...] >> SetThreadStackGuarantee (65536); > > Of course this only works "per thread", so if init_sigsegv is called > for the main thread, only the main thread gets this treatment. For > testing this should be enough, though. That didn't make any difference. But I do have a little more information. I tried running emacs under gdb with a breakpoint at handle_sigsegv. The breakpoint is hit when I deliberately trigger the stack overflow. Then I continue, emacs says it has recovered from the stack overflow, and I type 'C-x d'. At this point there's a second SIGSEGV and handle_sigsegv is called again. But this time garbage collection is in progress, and handle_sigsegv just gives up. I don't know what caused the second SIGSEGV but I'll try to figure that out when I next have a chance to look at this. I also don't know why the stack dump pointed to a crash while setting up the alternate stack, since the fatal crash actually seems to have happened later. But maybe the stack was just completely messed up after the second SIGSEGV and the stack dump can't be trusted. More later. 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