This is the mail archive of the
mailing list for the Cygwin project.
Re: (call-process ...) hangs in emacs
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin at cygwin dot com
- Date: Mon, 04 Aug 2014 09:34:20 -0400
- Subject: Re: (call-process ...) hangs in emacs
- Authentication-results: sourceware.org; auth=none
- References: <53DB8D23 dot 7060806 at alice dot it> <CAK9Gx1cjj-7cDP7CunD7Bxz35L+SU9+4Ro3HRot5cwjcArudOA at mail dot gmail dot com> <20140801133225 dot GD25860 at calimero dot vinschen dot de> <53DEDBBA dot 20102 at cornell dot edu> <20140804080034 dot GA2578 at calimero dot vinschen dot de>
On 8/4/2014 4:00 AM, Corinna Vinschen wrote:
On Aug 3 21:02, Ken Brown wrote:
On 8/1/2014 9:32 AM, Corinna Vinschen wrote:
On Aug 1 14:17, Peter Hull wrote:
On Fri, Aug 1, 2014 at 1:50 PM, Angelo Graziosi
Since I upgraded to Cygwin-1.7.31*, I see similar issue in building Emacs
trunk (--with-w32 build)... The build always hangs in compiling some .el
file. CTRL-C does not work and I have to search the running processes with
"ps" and kill them with 'kill -9'. Downgrading to 1.7.30, things work
better. Now I am using 1.7.30...
By better, do you mean 'perfectly'? It seems like it might be a little
bit intermittent, from the reports I have seen.
It's easy enough to do a cvs rdiff between the releases if 1.7.30 is
known to be good - I am happy to help but I am unfamiliar with the
code so I don't know where to start looking...
It could be a problem with the new default pthread mutexes being
NORMAL, rather then ERRORCHECK mutexes.
That does seem to be the problem, since I can reproduce the bug starting
with the 2014-07-14 snapshot. More precisely, I can reproduce it using
emacs-nox (which is what the OP was using according to his cygcheck output)
but not using emacs-X11 or emacs-w32.
I tried running emacs under gdb with a breakpoint at call_process, but all I
could see from that is that emacs tries to fork a subprocess, but the call
to fork() never returns. I also tried running it under strace, but again
all I can see is that fork() is called and then everything seems to be at a
Corinna, if you want to take a look, here's the precise recipe:
1. emacs-nox -Q [This should start emacs and put you in the *scratch*
2. Enter the following text into the buffer:
(call-process "pwd" nil t)
3. Position the cursor at the end of the line and type Ctrl-j.
What should happen, and what does happen prior to the 2014-07-14 snapshot,
is that the current directory is displayed, followed by the exit code of 0.
What happens instead is that emacs appears to hang.
How does emacs start a process? Does it create a thread and then
forks and execs from the thread? Does it use its own pthread_mutex
to control the job? Is there a chance to create an STC of this
emacs does some bookkeeping and then calls vfork. It does not create a
new thread, nor does it create a pthread_mutex. The only
pthread_mutexes created anywhere in the emacs source code are in its
implementation of malloc and friends, not in anything directly related
to controlling subprocesses. (FWIW, this malloc implementation is used
in the Cygwin build of emacs but not in the Linux build.)
I did think about trying to create an STC, but I'm stymied because the
problem depends so strongly on how emacs is run:
- If emacs is run interactively, the problem only occurs with
emacs-nox, not with emacs-X11 or emacs-w32.
- If emacs is run non-interactively (i.e., in batch mode), the problem
occurs with emacs-w32 and emacs-X11 too, as Angelo and Katsumi pointed
out earlier in the thread.
I can't think of any way to capture these peculiarities in an STC.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple