On Thu, 31 Jul 2014 15:51:49 +0100, Peter Hull wrote: > VC integration in emacs has stopped working for me in the past few > days. Using emacs debugger I found the last function call was to > call-process which never returns.
> I can reproduce this by evaluating in Lisp Interaction mode (using ^J) > (call-process "pwd" nil t) > I would expect to see the PWD and exit code but instead it just hangs > until I Quit it (^G) > I am using GNU Emacs 24.3.1 and confirmed cygwin and all packages up > to date. (cygwin DLL 1.7.31) I'm troubled with a similar problem since Wednesday[1]. /usr/bin/emacs that Cygwin distributed (24.3) seems ok, but /usr/local/bin/emacs that I built from the Emacs trunk Tuesday (24.4.50) got not to work conditionally. With that version of Emacs: Evaluating the form `(call-process "pwd" nil t)' on normally running Emacs works. It returns "/home/yamaoka" immediately. However, if it is done in the bacth mode, /usr/local/bin/emacs -Q -batch -eval '(call-process "pwd" nil t)' it never returns; the Emacs process eats no cpu but stays consistently[2]. `kill -9 PID' has no effect. Using the Windows Task Manager is the only means to kill it. I tried to rebuild that version of Emacs from scratch, but failed. During bootstrap, bootstrap-emacs for the first use never returns as follows (a trigger that makes bootstrap-emacs hang might be different, though): make[3]: Entering directory '/Work/emacs/lisp' EMACSLOADPATH= '../src/bootstrap-emacs.exe' -batch --no-site-file --no-site-lisp -l autoload \ --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \ --eval "(setq generated-autoload-file (expand-file-name (unmsys--file-name \"calendar/cal-loaddefs.el\")))" \ -f batch-update-autoloads ./calendar Wrote /Work/emacs/lisp/calendar/cal-loaddefs.el (Note: the cal-loaddefs.el file is created but bootstrap-emacs doesn't exit.) Thanks. [1] I did updating my Cygwin installation on Wednesday morning for the first time in the last 7 days. It must be the trigger of the problem. I also tried clean install of Cygwin, however it didn't help. Since it didn't seem to finish because of texlive-collection-basic.sh (the bash process didn't eat cpu, but never returned), I redid it by marking all the texlive packages to be `Skip'. [2] The configure script of some packages uses `call-process' in the batch mode of Emacs in order to examine something. It prevents the package from being built because of this problem. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple