GNU bug report logs - #18396
24.3.1; On windows, process-send-string can freeze Emacs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: 18396 <at> debbugs.gnu.org
Subject: bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs
Date: Wed, 03 Sep 2014 21:03:00 +0300

> From: Jorgen Schaefer <forcer <at> forcix.cx>
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.