From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Oct 2011 16:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 9767 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 9767@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.131878108131657 (code B ref -1); Sun, 16 Oct 2011 16:05:02 +0000 Received: (at submit) by debbugs.gnu.org; 16 Oct 2011 16:04:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RFTCa-0008EY-F9 for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:04:41 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RFTCX-0008EL-Kb for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:04:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFTBh-0004b0-5S for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:03:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:38343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFTBg-0004aw-Vy for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:03:45 -0400 Received: from eggs.gnu.org ([140.186.70.92]:60848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFTBg-0000bS-2t for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2011 12:03:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFTBe-0004al-OX for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2011 12:03:44 -0400 Received: from granite1.mail.cornell.edu ([128.253.83.141]:36821 helo=authusersmtp.mail.cornell.edu) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFTBe-0004aQ-LX for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2011 12:03:42 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9GG3ZDw004068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Oct 2011 12:03:36 -0400 (EDT) Message-ID: <4E9B0033.2070506@cornell.edu> Date: Sun, 16 Oct 2011 12:02:59 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) When I start a debugging session with M-x gdb, initialization doesn't appear to complete. I don't get the "(gdb)" prompt, and the mode line continues to say "initializing". If I press Return, I get the prompt and the mode line changes to "ready". Everything works fine after that. This seems Cygwin-specific; it doesn't happen on GNU/Linux. I've checked that all the strings that emacs sends to gdb during initialization (via gdb-input) do in fact get sent. And I've tried sending those same strings to gdb outside of emacs (except for "-inferior-tty-set..."), and nothing strange happened. In particular, I did have a "(gdb)" prompt at each stage. Does anyone have any suggestions as to what might cause this or how I can debug it? I don't have any experience with elisp debugging, so I would appreciate a few pointers to help get me started. Thanks. Ken In GNU Emacs 24.0.90.1 (i686-pc-cygwin, GTK+ Version 2.20.1) of 2011-09-26 on moufang Windowing system distributor `The Cygwin/X Project', version 11.0.11101000 configured using `configure '--srcdir=/usr/src/emacs-24.0.90-1/src/emacs-24.0.90' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--datadir=/usr/share' '--localstatedir=/var' '--sysconfdir=/etc' '--datarootdir=/usr/share' '--docdir=/usr/share/doc/emacs' '-C' 'CC=gcc' 'CFLAGS=-g -O2 From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Oct 2011 23:10: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: To: 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.13188065666770 (code B ref 9767); Sun, 16 Oct 2011 23:10:02 +0000 Received: (at 9767) by debbugs.gnu.org; 16 Oct 2011 23:09:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RFZpe-0001l9-5H for submit@debbugs.gnu.org; Sun, 16 Oct 2011 19:09:26 -0400 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 1RFZpb-0001l1-C8 for 9767@debbugs.gnu.org; Sun, 16 Oct 2011 19:09:24 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9GN8Y7M003441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <9767@debbugs.gnu.org>; Sun, 16 Oct 2011 19:08:34 -0400 (EDT) Message-ID: <4E9B63F0.5040409@cornell.edu> Date: Sun, 16 Oct 2011 19:08:32 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <4E9B0033.2070506@cornell.edu> In-Reply-To: <4E9B0033.2070506@cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) On 10/16/2011 12:02 PM, Ken Brown wrote: > When I start a debugging session with M-x gdb, initialization doesn't > appear to complete. I don't get the "(gdb)" prompt, and the mode line > continues to say "initializing". If I press Return, I get the prompt > and the mode line changes to "ready". Everything works fine after that. > This seems Cygwin-specific; it doesn't happen on GNU/Linux. > > I've checked that all the strings that emacs sends to gdb during > initialization (via gdb-input) do in fact get sent. And I've tried > sending those same strings to gdb outside of emacs (except for > "-inferior-tty-set..."), and nothing strange happened. In particular, I > did have a "(gdb)" prompt at each stage. Further info: It seems that initialization is actually completing, but for some reason the buffer is not being redisplayed. To test this, I inserted (sit-for .1) at the end of gdb-update to force redisplay, and that solved the problem. Unless someone who understands redisplay can figure out why redisplay isn't happening on Cygwin, I'm inclined to apply the following patch: === modified file 'lisp/progmodes/gdb-mi.el' --- lisp/progmodes/gdb-mi.el 2011-10-06 16:11:38 +0000 +++ lisp/progmodes/gdb-mi.el 2011-10-16 23:04:28 +0000 @@ -1726,7 +1726,8 @@ (gdb-force-mode-line-update (propertize "initializing..." 'face font-lock-variable-name-face)) (gdb-init-1) - (setq gdb-first-prompt nil)) + (setq gdb-first-prompt nil) + (if (eq system-type 'cygwin) (sit-for .1))) (gdb-get-main-selected-frame) ;; We may need to update gdb-threads-list so we can use Would this be reasonable? Ken From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Oct 2011 05:41: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: To: Ken Brown Cc: 9767@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.131883001210371 (code B ref 9767); Mon, 17 Oct 2011 05:41:02 +0000 Received: (at 9767) by debbugs.gnu.org; 17 Oct 2011 05:40:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RFfvn-0002hC-U7 for submit@debbugs.gnu.org; Mon, 17 Oct 2011 01:40:12 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RFfvm-0002h5-3O for 9767@debbugs.gnu.org; Mon, 17 Oct 2011 01:40:11 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RFfux-0003wt-EL; Mon, 17 Oct 2011 01:39:19 -0400 Date: Mon, 17 Oct 2011 01:39:19 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <4E9B63F0.5040409@cornell.edu> (message from Ken Brown on Sun, 16 Oct 2011 19:08:32 -0400) References: <4E9B0033.2070506@cornell.edu> <4E9B63F0.5040409@cornell.edu> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Sun, 16 Oct 2011 19:08:32 -0400 > From: Ken Brown > > Further info: It seems that initialization is actually completing, but > for some reason the buffer is not being redisplayed. To test this, I > inserted (sit-for .1) at the end of gdb-update to force redisplay, and > that solved the problem. Unless someone who understands redisplay can > figure out why redisplay isn't happening on Cygwin, I'm inclined to > apply the following patch: My crystal ball says that redisplay isn't happening because Emacs doesn't know that the GDB prompt has arrived. The call to sit-for causes Emacs to check its input descriptors, "discovering" that there is input. Please look around in wait_reading_process_output, and see what is going on there, before and after the call to sit-for. In particular, does the call to `select' report that input has arrived from GDB? > === modified file 'lisp/progmodes/gdb-mi.el' > --- lisp/progmodes/gdb-mi.el 2011-10-06 16:11:38 +0000 > +++ lisp/progmodes/gdb-mi.el 2011-10-16 23:04:28 +0000 > @@ -1726,7 +1726,8 @@ > (gdb-force-mode-line-update > (propertize "initializing..." 'face font-lock-variable-name-face)) > (gdb-init-1) > - (setq gdb-first-prompt nil)) > + (setq gdb-first-prompt nil) > + (if (eq system-type 'cygwin) (sit-for .1))) > > (gdb-get-main-selected-frame) > ;; We may need to update gdb-threads-list so we can use > > Would this be reasonable? I think it's not going to solve the real problem. If Emacs misses some of the output arriving from GDB, it will miss it again under similar circumstances. From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2011 20:02:01 +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: To: Eli Zaretskii Cc: 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.131905448210289 (code B ref 9767); Wed, 19 Oct 2011 20:02:01 +0000 Received: (at 9767) by debbugs.gnu.org; 19 Oct 2011 20:01:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGcKG-0002fr-KH for submit@debbugs.gnu.org; Wed, 19 Oct 2011 16:01:21 -0400 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 1RGcKB-0002fg-LR for 9767@debbugs.gnu.org; Wed, 19 Oct 2011 16:01:18 -0400 Received: from [128.84.234.241] (dhcp241.math.cornell.edu [128.84.234.241]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9JK09Xm004155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2011 16:00:10 -0400 (EDT) Message-ID: <4E9F2C49.4060307@cornell.edu> Date: Wed, 19 Oct 2011 16:00:09 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <4E9B0033.2070506@cornell.edu> <4E9B63F0.5040409@cornell.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.8 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.8 (-----) On 10/17/2011 1:39 AM, Eli Zaretskii wrote: >> Date: Sun, 16 Oct 2011 19:08:32 -0400 >> From: Ken Brown >> >> Further info: It seems that initialization is actually completing, but >> for some reason the buffer is not being redisplayed. To test this, I >> inserted (sit-for .1) at the end of gdb-update to force redisplay, and >> that solved the problem. Unless someone who understands redisplay can >> figure out why redisplay isn't happening on Cygwin, I'm inclined to >> apply the following patch: > > My crystal ball says that redisplay isn't happening because Emacs > doesn't know that the GDB prompt has arrived. The call to sit-for > causes Emacs to check its input descriptors, "discovering" that there > is input. > > Please look around in wait_reading_process_output, and see what is > going on there, before and after the call to sit-for. In particular, > does the call to `select' report that input has arrived from GDB? Thanks for the suggestions, Eli. First of all, I was wrong when I said that the problem was redisplay: using sleep-for instead of sit-for works just as well. As your crystal ball predicted, the problem is that emacs hasn't read its input from GDB. Here's what happens: After M-x gdb finishes its initialization, emacs goes into its command loop. read_char calls sit_for with a timeout of 30 seconds, and sit_for calls wait_reading_process_output, which calls select. The call to select fails immediately with EINTR. I don't understand the command loop well enough to know what's interrupting the select call. But select works fine in other settings (such as when I insert sleep-for in the gdb initialization). It seems that the problem is not really about M-x gdb, but about the emacs command loop. I see the same kinds of select failures (always with EINTR) if I just start up emacs and watch the calls to select during the command loop. The code in keyboard.c is full of alarms and timers, presumably related to polling for keyboard input. Could this polling be doing something that interrupts the select call under some circumstances? Ken From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2011 20:28:01 +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: To: Ken Brown Cc: 9767@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.131905606612516 (code B ref 9767); Wed, 19 Oct 2011 20:28:01 +0000 Received: (at 9767) by debbugs.gnu.org; 19 Oct 2011 20:27:46 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGcjp-0003Fo-O5 for submit@debbugs.gnu.org; Wed, 19 Oct 2011 16:27:45 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGcjn-0003FZ-CP for 9767@debbugs.gnu.org; Wed, 19 Oct 2011 16:27:44 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LTB00E00Y1JDD00@a-mtaout20.012.net.il> for 9767@debbugs.gnu.org; Wed, 19 Oct 2011 22:26:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.212.197]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LTB00DQSY46XQ80@a-mtaout20.012.net.il>; Wed, 19 Oct 2011 22:26:32 +0200 (IST) Date: Wed, 19 Oct 2011 22:26:32 +0200 From: Eli Zaretskii In-reply-to: <4E9F2C49.4060307@cornell.edu> X-012-Sender: halo1@inter.net.il Message-id: <83ipnku3rb.fsf@gnu.org> References: <4E9B0033.2070506@cornell.edu> <4E9B63F0.5040409@cornell.edu> <4E9F2C49.4060307@cornell.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Wed, 19 Oct 2011 16:00:09 -0400 > From: Ken Brown > CC: 9767@debbugs.gnu.org > > After M-x gdb finishes its initialization, emacs goes into its command > loop. read_char calls sit_for with a timeout of 30 seconds, and sit_for > calls wait_reading_process_output, which calls select. The call to > select fails immediately with EINTR. I don't understand the command > loop well enough to know what's interrupting the select call. EINTR means that some signal arrived (assuming that Cygwin's `select' is Posix-ish enough). The question is, which signal? Does Cygwin provide any tools to see which signals were delivered to a program? Also, the fact that `select' is interrupted doesn't necessarily mean that the input arrival is ignored, does it? Doesn't wait_reading_process_output loop around and examines the input descriptors again? If not, why not? IOW, why should EINTR become a failure? > The code in keyboard.c is full of alarms and timers, presumably related > to polling for keyboard input. Could this polling be doing something > that interrupts the select call under some circumstances? Atimers (those which are responsible for the "busy cursor" display) could deliver SIGALRM, yes. But again, I don't see why this should fail the loop that waits for input, and then only in this particular case. Something else is at work here. From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2011 20:45: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: To: Eli Zaretskii Cc: 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.131905705614055 (code B ref 9767); Wed, 19 Oct 2011 20:45:02 +0000 Received: (at 9767) by debbugs.gnu.org; 19 Oct 2011 20:44:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGczn-0003ee-Mu for submit@debbugs.gnu.org; Wed, 19 Oct 2011 16:44:16 -0400 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 1RGczk-0003eU-GO for 9767@debbugs.gnu.org; Wed, 19 Oct 2011 16:44:13 -0400 Received: from [128.84.234.241] (dhcp241.math.cornell.edu [128.84.234.241]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9JKh6tU012021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2011 16:43:07 -0400 (EDT) Message-ID: <4E9F365A.9060207@cornell.edu> Date: Wed, 19 Oct 2011 16:43:06 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <4E9B0033.2070506@cornell.edu> <4E9B63F0.5040409@cornell.edu> <4E9F2C49.4060307@cornell.edu> <83ipnku3rb.fsf@gnu.org> In-Reply-To: <83ipnku3rb.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.8 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.8 (-----) On 10/19/2011 4:26 PM, Eli Zaretskii wrote: >> Date: Wed, 19 Oct 2011 16:00:09 -0400 >> From: Ken Brown >> CC: 9767@debbugs.gnu.org >> >> After M-x gdb finishes its initialization, emacs goes into its command >> loop. read_char calls sit_for with a timeout of 30 seconds, and sit_for >> calls wait_reading_process_output, which calls select. The call to >> select fails immediately with EINTR. I don't understand the command >> loop well enough to know what's interrupting the select call. > > EINTR means that some signal arrived (assuming that Cygwin's `select' > is Posix-ish enough). The question is, which signal? Does Cygwin > provide any tools to see which signals were delivered to a program? There's a program called strace that produces lots of debugging information like this. I'll give it a try. > Also, the fact that `select' is interrupted doesn't necessarily mean > that the input arrival is ignored, does it? Doesn't > wait_reading_process_output loop around and examines the input > descriptors again? If not, why not? IOW, why should EINTR become a > failure? No, wait_reading_process_output treats EINTR as though it meant there's no input available. Here's the relevant code from process.c, line 4638. if (nfds < 0) { if (xerrno == EINTR) no_avail = 1; Even worse, xg_select (which is what the Cygwin build uses) deliberately returns -1 and sets errno = EINTR whenever the actual select call returns 0. Here's the code from xg_select.c, line 141: /* To not have to recalculate timeout, return like this. */ if (retval == 0) { retval = -1; errno = EINTR; } I don't know the rationale for treating EINTR the same as no input available, but I agree that it doesn't seem right. >> The code in keyboard.c is full of alarms and timers, presumably related >> to polling for keyboard input. Could this polling be doing something >> that interrupts the select call under some circumstances? > > Atimers (those which are responsible for the "busy cursor" display) > could deliver SIGALRM, yes. But again, I don't see why this should > fail the loop that waits for input, and then only in this particular > case. Something else is at work here. From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2011 21:05: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: To: Ken Brown Cc: Eli Zaretskii , 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.131905829915784 (code B ref 9767); Wed, 19 Oct 2011 21:05:02 +0000 Received: (at 9767) by debbugs.gnu.org; 19 Oct 2011 21:04:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGdJr-00046X-Jn for submit@debbugs.gnu.org; Wed, 19 Oct 2011 17:04:59 -0400 Received: from mail-out.m-online.net ([212.18.0.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGdJo-00046P-Jv for 9767@debbugs.gnu.org; Wed, 19 Oct 2011 17:04:57 -0400 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id A69A4188B5BC; Wed, 19 Oct 2011 23:03:24 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id A25081C002BA; Wed, 19 Oct 2011 23:03:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id HTZqz5cDlFHV; Wed, 19 Oct 2011 23:03:24 +0200 (CEST) Received: from igel.home (ppp-88-217-108-255.dynamic.mnet-online.de [88.217.108.255]) by mail.mnet-online.de (Postfix) with ESMTP; Wed, 19 Oct 2011 23:03:23 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id 76408CA29C; Wed, 19 Oct 2011 23:03:23 +0200 (CEST) From: Andreas Schwab References: <4E9B0033.2070506@cornell.edu> <4E9B63F0.5040409@cornell.edu> <4E9F2C49.4060307@cornell.edu> <83ipnku3rb.fsf@gnu.org> <4E9F365A.9060207@cornell.edu> X-Yow: I'm working under the direct orders of WAYNE NEWTON to deport consenting adults! Date: Wed, 19 Oct 2011 23:03:23 +0200 In-Reply-To: <4E9F365A.9060207@cornell.edu> (Ken Brown's message of "Wed, 19 Oct 2011 16:43:06 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2011 22:04: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: To: Andreas Schwab Cc: kbrown@cornell.edu, 9767@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.131906182820818 (code B ref 9767); Wed, 19 Oct 2011 22:04:02 +0000 Received: (at 9767) by debbugs.gnu.org; 19 Oct 2011 22:03:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGeEl-0005Pj-TP for submit@debbugs.gnu.org; Wed, 19 Oct 2011 18:03:48 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGeEi-0005PU-ST for 9767@debbugs.gnu.org; Wed, 19 Oct 2011 18:03:46 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LTC00I002FSDN00@a-mtaout21.012.net.il> for 9767@debbugs.gnu.org; Thu, 20 Oct 2011 00:02:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.212.197]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LTC00IDB2JRDH10@a-mtaout21.012.net.il>; Thu, 20 Oct 2011 00:02:18 +0200 (IST) Date: Thu, 20 Oct 2011 00:02:17 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fwiotzbq.fsf@gnu.org> References: <4E9B0033.2070506@cornell.edu> <4E9B63F0.5040409@cornell.edu> <4E9F2C49.4060307@cornell.edu> <83ipnku3rb.fsf@gnu.org> <4E9F365A.9060207@cornell.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > 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. So the question is still why no input is being reported, although wait_reading_process_output should loop and call `select' again. From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Oct 2011 02:14:01 +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: To: Eli Zaretskii Cc: Andreas Schwab , 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.131907678810061 (code B ref 9767); Thu, 20 Oct 2011 02:14:01 +0000 Received: (at 9767) by debbugs.gnu.org; 20 Oct 2011 02:13:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGi83-0002cD-O1 for submit@debbugs.gnu.org; Wed, 19 Oct 2011 22:13:08 -0400 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 1RGi80-0002c6-VW for 9767@debbugs.gnu.org; Wed, 19 Oct 2011 22:13:06 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9K2BvHK001536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2011 22:11:58 -0400 (EDT) Message-ID: <4E9F836A.5070505@cornell.edu> Date: Wed, 19 Oct 2011 22:11:54 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 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> In-Reply-To: <83fwiotzbq.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) 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. Ken From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin 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: To: Eli Zaretskii Cc: Andreas Schwab , 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.1319230152546 (code B ref 9767); Fri, 21 Oct 2011 20:50:02 +0000 Received: (at 9767) by debbugs.gnu.org; 21 Oct 2011 20:49:12 +0000 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 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 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) Message-ID: <4EA1DA78.5060404@cornell.edu> Date: Fri, 21 Oct 2011 16:47:52 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 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> In-Reply-To: <4E9F836A.5070505@cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.8 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.8 (-----) 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 From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Oct 2011 22:18:01 +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: To: Ken Brown Cc: schwab@linux-m68k.org, 9767@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.13192354277977 (code B ref 9767); Fri, 21 Oct 2011 22:18:01 +0000 Received: (at 9767) by debbugs.gnu.org; 21 Oct 2011 22:17:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHNOl-00024c-LX for submit@debbugs.gnu.org; Fri, 21 Oct 2011 18:17:07 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHNOj-000244-Fx for 9767@debbugs.gnu.org; Fri, 21 Oct 2011 18:17:06 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LTF00A00S9XJJ00@a-mtaout22.012.net.il> for 9767@debbugs.gnu.org; Sat, 22 Oct 2011 00:15:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.212.197]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LTF00AFWSI54AC0@a-mtaout22.012.net.il>; Sat, 22 Oct 2011 00:15:42 +0200 (IST) Date: Sat, 22 Oct 2011 00:15:45 +0200 From: Eli Zaretskii In-reply-to: <4EA1DA78.5060404@cornell.edu> X-012-Sender: halo1@inter.net.il Message-id: <83k47yq9da.fsf@gnu.org> 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> <4EA1DA78.5060404@cornell.edu> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Fri, 21 Oct 2011 16:47:52 -0400 > From: Ken Brown > CC: Andreas Schwab , 9767@debbugs.gnu.org > > 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). Why does reducing the timeout works on, say, GNU/Linux, but not on Cygwin? What is different? Clock granularity, perhaps? From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Oct 2011 22:26:01 +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: To: Ken Brown Cc: Eli Zaretskii , Andreas Schwab , 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.13192359338695 (code B ref 9767); Fri, 21 Oct 2011 22:26:01 +0000 Received: (at 9767) by debbugs.gnu.org; 21 Oct 2011 22:25:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHNWu-0002GA-FD for submit@debbugs.gnu.org; Fri, 21 Oct 2011 18:25:33 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHNWs-0002Fz-BL for 9767@debbugs.gnu.org; Fri, 21 Oct 2011 18:25:31 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALnwoU5MCqLO/2dsb2JhbABDDqkQgQaBbgEBBAFWIwULCw4mEhQYDSSIE7QFiEAEoTKDclM X-IronPort-AV: E=Sophos;i="4.69,388,1315195200"; d="scan'208";a="143661113" Received: from 76-10-162-206.dsl.teksavvy.com (HELO pastel.home) ([76.10.162.206]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 21 Oct 2011 18:24:01 -0400 Received: by pastel.home (Postfix, from userid 20848) id D8188591FD; Fri, 21 Oct 2011 18:24:00 -0400 (EDT) From: Stefan Monnier Message-ID: 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> <4EA1DA78.5060404@cornell.edu> Date: Fri, 21 Oct 2011 18:24:00 -0400 In-Reply-To: <4EA1DA78.5060404@cornell.edu> (Ken Brown's message of "Fri, 21 Oct 2011 16:47:52 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > 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). Why is it a problem that `select' fails? It should not be a problem: in the worst case it should only mean that Emacs does "busy waiting" and uses up more CPU than needed. But it shouldn't prevent Emacs from reading input from processes (which IIUC is the actual problem we're trying to solve). Stefan From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Oct 2011 09:49:01 +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: To: Stefan Monnier Cc: Eli Zaretskii , Andreas Schwab , 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.13192769313057 (code B ref 9767); Sat, 22 Oct 2011 09:49:01 +0000 Received: (at 9767) by debbugs.gnu.org; 22 Oct 2011 09:48:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHYCA-0000nF-LC for submit@debbugs.gnu.org; Sat, 22 Oct 2011 05:48:51 -0400 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 1RHYC8-0000n7-3u for 9767@debbugs.gnu.org; Sat, 22 Oct 2011 05:48:49 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9M9lQda018299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Oct 2011 05:47:27 -0400 (EDT) Message-ID: <4EA2912C.7020505@cornell.edu> Date: Sat, 22 Oct 2011 05:47:24 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 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> <4EA1DA78.5060404@cornell.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) On 10/21/2011 6:24 PM, Stefan Monnier wrote: >> 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). > > Why is it a problem that `select' fails? It should not be a problem: in > the worst case it should only mean that Emacs does "busy waiting" and > uses up more CPU than needed. But it shouldn't prevent Emacs from > reading input from processes (which IIUC is the actual problem we're > trying to solve). You're right. I wasn't thinking clearly. The problem is not solved. Ken From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Oct 2011 09:53: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: To: Eli Zaretskii Cc: schwab@linux-m68k.org, 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.13192771553391 (code B ref 9767); Sat, 22 Oct 2011 09:53:02 +0000 Received: (at 9767) by debbugs.gnu.org; 22 Oct 2011 09:52:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHYFm-0000sd-Dd for submit@debbugs.gnu.org; Sat, 22 Oct 2011 05:52:34 -0400 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 1RHYFj-0000sT-WA for 9767@debbugs.gnu.org; Sat, 22 Oct 2011 05:52:33 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9M9pBFl018749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Oct 2011 05:51:12 -0400 (EDT) Message-ID: <4EA2920D.9090809@cornell.edu> Date: Sat, 22 Oct 2011 05:51:09 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 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> <4EA1DA78.5060404@cornell.edu> <83k47yq9da.fsf@gnu.org> In-Reply-To: <83k47yq9da.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) On 10/21/2011 6:15 PM, Eli Zaretskii wrote: >> Date: Fri, 21 Oct 2011 16:47:52 -0400 >> From: Ken Brown >> CC: Andreas Schwab, 9767@debbugs.gnu.org >> >> 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). > > Why does reducing the timeout works on, say, GNU/Linux, but not on > Cygwin? What is different? Clock granularity, perhaps? Sorry, I'm wrong again. As Stefan pointed out, it's harmless that select gets interrupted by SIGALRM. That can't explain the gdb problem, which still isn't solved. Ken From unknown Tue Jun 24 20:52:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9767: 24.0.90; gdb initialization on Cygwin Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Oct 2011 21:00:01 +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: To: Eli Zaretskii Cc: schwab@linux-m68k.org, 9767@debbugs.gnu.org Received: via spool by 9767-submit@debbugs.gnu.org id=B9767.1319317189317 (code B ref 9767); Sat, 22 Oct 2011 21:00:01 +0000 Received: (at 9767) by debbugs.gnu.org; 22 Oct 2011 20:59:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RHifU-000054-Ax for submit@debbugs.gnu.org; Sat, 22 Oct 2011 16:59:48 -0400 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 1RHifQ-00004v-Gf for 9767@debbugs.gnu.org; Sat, 22 Oct 2011 16:59:46 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9MKwKQ6017711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Oct 2011 16:58:21 -0400 (EDT) Message-ID: <4EA32E68.2030803@cornell.edu> Date: Sat, 22 Oct 2011 16:58:16 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 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> <4EA1DA78.5060404@cornell.edu> <83k47yq9da.fsf@gnu.org> <4EA2920D.9090809@cornell.edu> In-Reply-To: <4EA2920D.9090809@cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) For the third (and final?) time, I think I've figured out the problem. It has nothing to do with emacs or select, but is simply a problem with Cygwin's gdb. When the current Cygwin gdb is given too many input lines before having its output read, it sometimes stops producing output and waits for the user to press Return. This is what was happening during the initialization of M-x gdb, and that explains why I could work around the problem by inserting (sleep-for .1) before the initialization was finished. I've found a way to reliably reproduce this, and I've reported it to the Cygwin list. I'm not closing this bug report yet because I want to wait and see how the Cygwin problem is resolved. It may still be necessary to use some kind of workaround. Thanks to all who tried to help and who put up with my mistakes and misunderstandings. Ken From unknown Tue Jun 24 20:52:02 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Ken Brown Subject: bug#9767: closed (Re: bug#9767: 24.0.90; gdb initialization on Cygwin) Message-ID: References: <4EA48E3F.2000805@cornell.edu> <4E9B0033.2070506@cornell.edu> X-Gnu-PR-Message: they-closed 9767 X-Gnu-PR-Package: emacs Reply-To: 9767@debbugs.gnu.org Date: Sun, 23 Oct 2011 22:02:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1319407322-5068-1" This is a multi-part message in MIME format... ------------=_1319407322-5068-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #9767: 24.0.90; gdb initialization on Cygwin which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 9767@debbugs.gnu.org. --=20 9767: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D9767 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1319407322-5068-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 9767-done) by debbugs.gnu.org; 23 Oct 2011 22:01:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RI66J-0001IG-8X for submit@debbugs.gnu.org; Sun, 23 Oct 2011 18:01:03 -0400 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 1RI66G-0001Hq-9B for 9767-done@debbugs.gnu.org; Sun, 23 Oct 2011 18:01:01 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9NLxUu3007005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Oct 2011 17:59:31 -0400 (EDT) Message-ID: <4EA48E3F.2000805@cornell.edu> Date: Sun, 23 Oct 2011 17:59:27 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#9767: 24.0.90; gdb initialization on Cygwin 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> <4EA1DA78.5060404@cornell.edu> <83k47yq9da.fsf@gnu.org> <4EA2920D.9090809@cornell.edu> <4EA32E68.2030803@cornell.edu> In-Reply-To: <4EA32E68.2030803@cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: 9767-done Cc: schwab@linux-m68k.org, 9767-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) On 10/22/2011 4:58 PM, Ken Brown wrote: > I'm not closing this bug report yet because I want to wait and see how > the Cygwin problem is resolved. This has now been fixed in the Cygwin development trunk. The fix will be in Cygwin 1.7.10, which will probably be released before Emacs 24.1, so I'm closing the bug. ------------=_1319407322-5068-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 16 Oct 2011 16:04:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RFTCa-0008EY-F9 for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:04:41 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RFTCX-0008EL-Kb for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:04:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFTBh-0004b0-5S for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:03:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:38343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFTBg-0004aw-Vy for submit@debbugs.gnu.org; Sun, 16 Oct 2011 12:03:45 -0400 Received: from eggs.gnu.org ([140.186.70.92]:60848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFTBg-0000bS-2t for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2011 12:03:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFTBe-0004al-OX for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2011 12:03:44 -0400 Received: from granite1.mail.cornell.edu ([128.253.83.141]:36821 helo=authusersmtp.mail.cornell.edu) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFTBe-0004aQ-LX for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2011 12:03:42 -0400 Received: from [192.168.1.3] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9GG3ZDw004068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Oct 2011 12:03:36 -0400 (EDT) Message-ID: <4E9B0033.2070506@cornell.edu> Date: Sun, 16 Oct 2011 12:02:59 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: 24.0.90; gdb initialization on Cygwin Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) When I start a debugging session with M-x gdb, initialization doesn't appear to complete. I don't get the "(gdb)" prompt, and the mode line continues to say "initializing". If I press Return, I get the prompt and the mode line changes to "ready". Everything works fine after that. This seems Cygwin-specific; it doesn't happen on GNU/Linux. I've checked that all the strings that emacs sends to gdb during initialization (via gdb-input) do in fact get sent. And I've tried sending those same strings to gdb outside of emacs (except for "-inferior-tty-set..."), and nothing strange happened. In particular, I did have a "(gdb)" prompt at each stage. Does anyone have any suggestions as to what might cause this or how I can debug it? I don't have any experience with elisp debugging, so I would appreciate a few pointers to help get me started. Thanks. Ken In GNU Emacs 24.0.90.1 (i686-pc-cygwin, GTK+ Version 2.20.1) of 2011-09-26 on moufang Windowing system distributor `The Cygwin/X Project', version 11.0.11101000 configured using `configure '--srcdir=/usr/src/emacs-24.0.90-1/src/emacs-24.0.90' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--datadir=/usr/share' '--localstatedir=/var' '--sysconfdir=/etc' '--datarootdir=/usr/share' '--docdir=/usr/share/doc/emacs' '-C' 'CC=gcc' 'CFLAGS=-g -O2 ------------=_1319407322-5068-1--