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: Jorgen Schaefer <forcer <at> forcix.cx>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18396 <at> 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

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

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

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

Previous Next

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