From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.bugs Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Date: Fri, 21 Oct 2011 16:47:52 -0400 Message-ID: <4EA1DA78.5060404@cornell.edu> References: <4E9B0033.2070506@cornell.edu> <4E9B63F0.5040409@cornell.edu> <4E9F2C49.4060307@cornell.edu> <83ipnku3rb.fsf@gnu.org> <4E9F365A.9060207@cornell.edu> <83fwiotzbq.fsf@gnu.org> <4E9F836A.5070505@cornell.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1319230140 24062 80.91.229.12 (21 Oct 2011 20:49:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2011 20:49:00 +0000 (UTC) Cc: Andreas Schwab , 9767@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 21 22:48:54 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RHM1N-0005u5-Re for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Oct 2011 22:48:53 +0200 Original-Received: from localhost ([::1]:59937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHM1N-0003pZ-9J for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Oct 2011 16:48:53 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHM1I-0003pS-DC for bug-gnu-emacs@gnu.org; Fri, 21 Oct 2011 16:48:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHM1H-0004JW-6o for bug-gnu-emacs@gnu.org; Fri, 21 Oct 2011 16:48:48 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHM1H-0004JM-3m for bug-gnu-emacs@gnu.org; Fri, 21 Oct 2011 16:48:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RHM2U-00009u-F7 for bug-gnu-emacs@gnu.org; Fri, 21 Oct 2011 16:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Oct 2011 20:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9767 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.1319230152546 (code B ref 9767); Fri, 21 Oct 2011 20:50:02 +0000 Original-Received: (at 9767) by debbugs.gnu.org; 21 Oct 2011 20:49:12 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHM1g-00008k-15 for submit@debbugs.gnu.org; Fri, 21 Oct 2011 16:49:12 -0400 Original-Received: from granite1.mail.cornell.edu ([128.253.83.141] helo=authusersmtp.mail.cornell.edu) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHM1c-00008a-GE for 9767@debbugs.gnu.org; Fri, 21 Oct 2011 16:49:10 -0400 Original-Received: from [128.84.234.240] (dhcp240.math.cornell.edu [128.84.234.240]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9LKlpEQ024701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Oct 2011 16:47:51 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: <4E9F836A.5070505@cornell.edu> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 21 Oct 2011 16:50:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:53004 Archived-At: On 10/19/2011 10:11 PM, Ken Brown wrote: > On 10/19/2011 6:02 PM, Eli Zaretskii wrote: >>> From: Andreas Schwab >>> Cc: Eli Zaretskii, 9767@debbugs.gnu.org >>> Date: Wed, 19 Oct 2011 23:03:23 +0200 >>> >>> Ken Brown writes: >>> >>>> No, wait_reading_process_output treats EINTR as though it meant >>>> there's no >>>> input available. >>> >>> Which is correct because an interrupted select does not report anything. >>> And then the loop will be restarted to call select again. >> >> Yes, that's what I thought should be happening. Sorry if that was >> unclear. > > You were clear. I was the one who muddied the waters by misreading the > code, and Andreas correctly pointed out that I was wrong. > >> So the question is still why no input is being reported, although >> wait_reading_process_output should loop and call `select' again. > > Yes, that's the question. I'll have to go back to my debugging. OK, I figured out what's happening, and it is related to SIGALRM after all. In line 4406 of process.c, wait_reading_process_output reduces the timeout for the select call (under certain circumstances) in an attempt to prevent select from being interrupted by SIGALRM. This seems to me to be inherently unreliable, and, in particular, it consistently fails on Cygwin. In other words, the SIGALRM is delivered before select times out, causing select to get interrupted. So wait_reading_process_output does indeed loop, and select fails every time (except when a key is pressed). If I block SIGALRM before the call to select (in the situation where the timeout was reduced), the problem is solved. I need to do some more testing, but so far I don't see any sign that this causes other problems. One tricky thing is that blocking SIGALRM has to be done right before the call to the *system* select. In the build with GTK support, this call is inside xg_select, and things break if SIGALRM is blocked before the call to xg_select. So I'm not sure what's the best way to handle this. I'll keep thinking about it, but suggestions are welcome. Ken