unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jorgen Schaefer <forcer@forcix.cx>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 18396@debbugs.gnu.org
Subject: bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs
Date: Wed, 3 Sep 2014 20:43:07 +0200	[thread overview]
Message-ID: <20140903204307.0bcf515c@forcix> (raw)
In-Reply-To: <831trsinu3.fsf@gnu.org>

On Wed, 03 Sep 2014 21:03:00 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Jorgen Schaefer <forcer@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.

After your explanation, I'm not so sure, either.
 
> > 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.

What would be the equivalent for "out of the way and not blocking any
mount point" (or equivalent) on 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?

The same would happen on Unix, except the buffer size is much larger,
meaning it's a lot less likely.

I guess the Python process could use threading to avoid this.

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'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.

Thanks. I'll ask, though I'm not sure if the user has a debugger
available.

Jorgen





  reply	other threads:[~2014-09-03 18:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03 16:58 bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs Jorgen Schaefer
2014-09-03 18:03 ` Eli Zaretskii
2014-09-03 18:43   ` Jorgen Schaefer [this message]
2014-09-03 19:01     ` Eli Zaretskii
2014-09-03 19:28       ` Jorgen Schaefer
2014-09-04  2:51         ` Eli Zaretskii
2014-09-09 18:45           ` Eli Zaretskii
2014-11-01 15:37 ` bug#18396: No further updates Jorgen Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140903204307.0bcf515c@forcix \
    --to=forcer@forcix.cx \
    --cc=18396@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).