From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs Date: Wed, 03 Sep 2014 21:03:00 +0300 Message-ID: <831trsinu3.fsf@gnu.org> References: <87k35kod3w.fsf@loki.jorgenschaefer.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1409767407 29060 80.91.229.3 (3 Sep 2014 18:03:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2014 18:03:27 +0000 (UTC) Cc: 18396@debbugs.gnu.org To: Jorgen Schaefer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 03 20:03:20 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 1XPEtq-0001DS-D8 for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2014 20:03:18 +0200 Original-Received: from localhost ([::1]:46986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPEtp-00074E-Kl for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2014 14:03:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPEth-00072L-4F for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 14:03:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPEta-0006dm-SQ for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 14:03:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPEta-0006dg-OV for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 14:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XPEta-0001Om-29 for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 14:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2014 18:03:02 +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: Original-Received: via spool by 18396-submit@debbugs.gnu.org id=B18396.14097673815370 (code B ref 18396); Wed, 03 Sep 2014 18:03:02 +0000 Original-Received: (at 18396) by debbugs.gnu.org; 3 Sep 2014 18:03:01 +0000 Original-Received: from localhost ([127.0.0.1]:58063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPEtY-0001OW-Ce for submit@debbugs.gnu.org; Wed, 03 Sep 2014 14:03:00 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:33952) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPEtV-0001OH-30 for 18396@debbugs.gnu.org; Wed, 03 Sep 2014 14:02:58 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NBC00H00797EY00@a-mtaout20.012.net.il> for 18396@debbugs.gnu.org; Wed, 03 Sep 2014 21:02:50 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBC00HPN7GP0G60@a-mtaout20.012.net.il>; Wed, 03 Sep 2014 21:02:50 +0300 (IDT) In-reply-to: <87k35kod3w.fsf@loki.jorgenschaefer.de> X-012-Sender: halo1@inter.net.il 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:92995 Archived-At: > From: Jorgen Schaefer > Date: Wed, 03 Sep 2014 18:58:11 +0200 > > A user's bug report[1] on my project Elpy has revealed an apparent bug > in Emacs. I'm not sure it is a bug in Emacs. > Elpy starts a Python process using `start-process' with > `process-connection-type' set to nil, `default-directory' set to "/", > and an unchanged coding system. Using "/" as the default directory on Windows is a bad idea, as that is not a fully-qualified absolute file name. > After some interactions, this freezes an Emacs under Windows. C-g does > not lead to any reaction. On Windows, C-g cannot interrupt a system call. > Killing the subprocess unfreezes Emacs. Probably because it breaks the pipe to the subprocess. Which probably means Emacs is not hung, it waits for something that doesn't happen. > The freeze happens more reliably the larger the data sent is. This is consistent with the pipe not being read hypothesis, see below. > (defun elpy-rpc--call (method-name params success error) > (let ((promise (elpy-promise success error))) > (with-current-buffer (elpy-rpc--get-rpc-buffer) > (setq elpy-rpc--call-id (1+ elpy-rpc--call-id)) > (elpy-rpc--register-callback elpy-rpc--call-id promise) > (let ((proc (get-buffer-process (current-buffer))) > (text (json-encode `((id . ,elpy-rpc--call-id) > (method . ,method-name) > (params . ,params))))) > (message "Sending %s bytes ..." (length text)) > (process-send-string proc text) > (process-send-string proc "\n") > (message "Sending %s bytes ... done." (length text)))) > promise)) > > This lead to the following output in *Messages*: > > Sending 978 bytes ... done. > Sending 958 bytes ... done. > Sending 959 bytes ... done. > Sending 960 bytes ... done. > Sending 961 bytes ... done. > Sending 962 bytes ... done. > Sending 958 bytes ... > > At this point, Emacs froze. Apparently, it did so in the middle of one > of the two `process-send-string' calls. Killing the subprocess caused > the following output: > > eldoc error: (file-error writing to process invalid argument elpy-rpc [project:~/ python:pythonw]) 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). > I'm a bit at a loss now as to how to continue debugging this. 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. > (Windows doesn't have strace, does it?). It does, but you don't want to use that, believe me: you would be drowned in a flood of system calls, most of which are undocumented, and even if they were, it is entirely non-obvious how to relate them to what Emacs does.