From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.bugs Subject: bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs Date: Wed, 3 Sep 2014 21:28:33 +0200 Message-ID: <20140903212833.14562b90@forcix> References: <87k35kod3w.fsf@loki.jorgenschaefer.de> <831trsinu3.fsf@gnu.org> <20140903204307.0bcf515c@forcix> <83zjegh6kh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1409772565 32206 80.91.229.3 (3 Sep 2014 19:29:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2014 19:29:25 +0000 (UTC) Cc: 18396@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 03 21:29:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPGF3-0000ex-9d for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2014 21:29:17 +0200 Original-Received: from localhost ([::1]:47296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPGF2-0005UG-MM for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2014 15:29:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPGEt-0005Sv-Nj for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 15:29:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPGEo-00027V-D5 for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 15:29:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPGEo-00027R-AE for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 15:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XPGEn-0003ZH-W0 for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 15:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jorgen Schaefer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2014 19:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18396 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 18396-submit@debbugs.gnu.org id=B18396.140977252013671 (code B ref 18396); Wed, 03 Sep 2014 19:29:01 +0000 Original-Received: (at 18396) by debbugs.gnu.org; 3 Sep 2014 19:28:40 +0000 Original-Received: from localhost ([127.0.0.1]:58116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPGER-0003YQ-Tb for submit@debbugs.gnu.org; Wed, 03 Sep 2014 15:28:40 -0400 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:37409) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPGEP-0003YF-Fn for 18396@debbugs.gnu.org; Wed, 03 Sep 2014 15:28:38 -0400 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id 5ECD3202AB7; Wed, 3 Sep 2014 21:28:35 +0200 (CEST) Original-Received: from forcix (port-52353.pppoe.wtnet.de [46.59.205.39]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id 96C392011DA; Wed, 3 Sep 2014 21:28:34 +0200 (CEST) In-Reply-To: <83zjegh6kh.fsf@gnu.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; i586-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:93002 Archived-At: On Wed, 03 Sep 2014 22:01:18 +0300 Eli Zaretskii wrote: > > Date: Wed, 3 Sep 2014 20:43:07 +0200 > > From: Jorgen Schaefer > > Cc: 18396@debbugs.gnu.org > > > > > Using "/" as the default directory on Windows is a bad idea, as > > > that is not a fully-qualified absolute file name. > > > > What would be the equivalent for "out of the way and not blocking > > any mount point" (or equivalent) on Windows? > > I might have a suggestion, if you explain what "out of the way" and > "not blocking any mount points" mean. The primary reason Elpy starts the process in "/" is to avoid accidental imports of Python modules. As the process is started from a Python buffer, there often are Python files in the current directory, which can accidentally be imported. "/" is unlikely to have Python modules. Also, a current directory of "/" means the process won't accidentally block a mount point, much like why daemons chdir to /. I'm not sure if this concept makes sense in Windows. > > > Looks like the write to the pipe never returned. This could be > > > because the pipe is full and is not being read from the other end > > > (Windows pipes have 4K buffers, and you show above more than 6K of > > > data). > > > > That is quite likely the explanation. The Python process does the > > equivalent of a REPL, reading one RPC call, evaluating it, and > > writing the response. If in the duration of that evaluation Emacs > > sends more than 4k of data, it will hang. If the response is larger > > than 4k, Python in turn will hang. Resulting in a deadlock. > > > > Am I missing something? > > I'd expect Python to continue reading from the pipe once it evaluated > one call and sent back the response. It should see that more input is > available and continue reading. But if the sending of the response runs into the same problem? The response can contain docstrings and can easily be larger than 4k, so it's conceivable that Python sends more than 4k of data as well, which would block the Python process, too? And thus prevent it from reading, which keeps Emacs blocked? > Could this be an end-of-line format issue? Are you sure the commands > used from Emacs side produce Windows-style CRLF EOLs? Or maybe they > do, but Python expects Unix-style newline-only EOLs (maybe it's a > Cygwin or MSYS Python, for example)? A wrong EOL format might cause > Python to fail to realize it was handed a full line of input. Unlikely. The RPC calls work perfectly fine most of the time, so the line ending convention does not cause any confusion. Also, changing the line ending convention on the Emacs side caused an error, so I assume it's working fine as is. > > Does Emacs have a chance to check for a pipe to be writable before > > doing so? The whole process blocking like this feels a bit weird. > > I don't know how to do such a check with pipes on Windows. More > importantly, how would that help? The pipe will fill up anyway, and > the communications with Python will stop. Being able to interrupt > with C-g vs killing the subprocess is not such a big win, IMO. Well, if the deadlock hypothesis is correct, Emacs would check if the pipe is writable, notice that it isn't and keep checking, to notice that the pipe is readable, read data, and thus break the deadlock. That of course requires that the deadlock hypothesis is indeed correct. :-) > > > The obvious way: attach a debugger to Emacs and see where it is > > > hung or waiting. It is important to ask the user to produce > > > backtraces from all the threads, because at least 2 threads are > > > involved in interaction with a subprocess on MS-Windows. > > > > Thanks. I'll ask, though I'm not sure if the user has a debugger > > available. > > If the user doesn't have GDB, he/she can download one from the MinGW > site. I think using a debugger is the only way to understand what > happens here. I'll pass it on, thanks. Jorgen