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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#18396: closed (24.3.1; On windows, process-send-string can
 freeze Emacs)
Date: Sat, 01 Nov 2014 15:39:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 1 Nov 2014 16:37:57 +0100
with message-id <20141101163757.2b23689a <at> forcix>
and subject line No further updates
has caused the debbugs.gnu.org bug report #18396,
regarding 24.3.1; On windows, process-send-string can freeze Emacs
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
18396: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18396
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jorgen Schaefer <forcer <at> forcix.cx>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.1; On windows, process-send-string can freeze Emacs
Date: Wed, 03 Sep 2014 18:58:11 +0200

Hi!
A user's bug report[1] on my project Elpy has revealed an apparent bug
in Emacs.

[1] https://github.com/jorgenschaefer/elpy/issues/212#issuecomment-54015294

Elpy starts a Python process using `start-process' with
`process-connection-type' set to nil, `default-directory' set to "/",
and an unchanged coding system. It then proceeds to talk with the
subprocess using a JSON-RPC-based protocol.

After some interactions, this freezes an Emacs under Windows. C-g does
not lead to any reaction. Killing the subprocess unfreezes Emacs. The
freeze happens more reliably the larger the data sent is.

I asked the user to change the function that does the process
communication to the following:

(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])

Elpy indeed is called from eldoc, and "elpy-rpc [project:~/
python:pythonw]" is the process name.

I'm a bit at a loss now as to how to continue debugging this. I do not
use Windows myself. I'm sure the user is willing to do some debugging
and reproduction cases there, but I wouldn't even know how to start or
what to ask them to do (Windows doesn't have strace, does it?).

Jorgen

[Message part 3 (message/rfc822, inline)]

From: Jorgen Schaefer <forcer <at> forcix.cx>
To: 18396-close <at> debbugs.gnu.org
Subject: No further updates
Date: Sat, 1 Nov 2014 16:37:57 +0100

The user did not provide any further feedback after three weeks.
Closing this bug report, assuming the problem was fixed.

Thank you!

Previous Next

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