bug#10674: 24.0.92; cmdproxy.exe fork-bomb

[Eli Zaretskii <eliz@gnu.org>]

> From: sjm@spamcop.net
> Date: Tue, 31 Jan 2012 03:12:37 +0000
> 
> How to fork-bomb Windows in 4 simple steps:
> 
> 1. M-x customize-browse
> 2. Click "Programming"
> 3. Click "Languages"
> 4. Wait
> 
> Your process list should quickly get flooded with copies of cmdproxy.exe
> and Windows should soon grind to a halt.

I cannot reproduce this, no matter how hard I try.  I tried half a
dozen of different Emacs binaries, including the very same you used:

> In GNU Emacs 24.0.92.1 (i386-mingw-nt6.1.7601)
>  of 2012-01-23 on MARVIN

which is the latest weekly snapshot of the development trunk, and also
several others.  I did that on 2 different machines.  None of these
flooded my system with copies of cmdproxy.  They all worked as
expected, showing the list of programming languages supported by Emacs
modes.

So something else is at work here that exists on your machine, but not
on mine.  One difference is that my machines run Windows XP, not
Windows 7.  But I don't think this is the first thing I'd suspect.

First, does this happen in "emacs -Q" for you?  If not, please look in
your .emacs for possible reasons.

If "emacs -Q" produces the problem, then the only invocation of
cmdproxy in the sequence you describe is in python.el, in the function
python-check-version, which invokes "python -V" and parses its
output.  Do you have Python installed, and if so, is python.exe on
your PATH?  Also, does the following command works as expected, or
does it also produce the same problem?

  M-: (shell-command-to-string "python -V") RET

Finally, please make sure Emacs picks up the correct binary of
cmdproxy.exe, the correct binary of python.exe (if it is installed),
and your python.elc is not corrupted (recompile it to be sure, or
manually load python.el before doing the sequence that triggered the
bug).