Aneesh aneeshb...@gmail.com added the comment:
I too retested this on a Windows 7 32 and 64 bit machines and is working fine
when the provided PyShell.py is used.
As Terry mentioned, IDLE seems be running better. The process in Task Manager
disappears quickly after I close the IDLE.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset cc86f4ca5020 by Ned Deily in branch '3.2':
Issue #12540: Prevent zombie IDLE processes on Windows due to changes
http://hg.python.org/cpython/rev/cc86f4ca5020
New changeset c2fd1ce1c6d4 by Ned Deily in branch
Ned Deily n...@acm.org added the comment:
With Eli's concurrence, I have applied the updated patch to 3.2 (for 3.2.2) and
to default (for 3.3).
--
assignee: - ned.deily
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
Eli Bendersky eli...@gmail.com added the comment:
On Fri, Aug 5, 2011 at 09:43, Ned Deily rep...@bugs.python.org wrote:
Ned Deily n...@acm.org added the comment:
With Eli's concurrence, I have applied the updated patch to 3.2 (for 3.2.2)
and to default (for 3.3).
--
Tested this
Terry J. Reedy tjre...@udel.edu added the comment:
The replacement file, for anyone without a dev setup, is
http://hg.python.org/cpython/file/cc86f4ca5020/Lib/idlelib/PyShell.py
After renaming PyShell to PyShellBak and replacing with the above,
IDLE seems to run better than ever. On my XP
Peter Caven pca...@gmail.com added the comment:
Terry, sorry about the delay in responding: I'm using 32bit Python. I haven't
had a chance yet to try the 64 bit release.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
Ned Deily n...@acm.org added the comment:
I've added a couple of review comments to the one Peter already made in
Rietveld. Here is an updated patch that addresses all of the comments. I've
tested in briefly on Windows and on OS X and it seems to work OK. Eli, if
you're OK with it, feel
Eli Bendersky eli...@gmail.com added the comment:
Terry,
When I tried the same fix in idlelib/PyShell.py, adding 'import subprocess'
and changing
self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args)
to
self.rpcpid = subprocess.Popen(args).pid
(args begins with
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: -haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
___
___
Terry J. Reedy tjre...@udel.edu added the comment:
I was working with the freshly reinstalled 3.2 which is not the same as a
pristine 3.2 install because it still had the problem that 3.2.1 has and the
3.2.1 sys.version. 3.2.1 uninstall in not complete (a different issue). So I
should
Eli Bendersky eli...@gmail.com added the comment:
Attaching an initial patch for Lib/idlelib/PyShell.py
It uses subprocess.Popen instead of spawnkill, in the way discussed in earlier
messages.
As far as I can tell, IDLE opens and restarts shells successfully, without
leaving zombies behind.
Eli Bendersky eli...@gmail.com added the comment:
I've now tested this on Ubuntu Linux as well. IDLE works, no zombies left
behind.
--
keywords: -patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
Terry J. Reedy tjre...@udel.edu added the comment:
I mentioned pipes because half of the subprocess chapter, it seems, talks about
them. ASo I got the mis-impression that they are special for subprocess-started
processes. But if the subprocess gets the args it needs to connect to a socket,
it
Eli Bendersky eli...@gmail.com added the comment:
OK, I can reproduce the problem on a clean virtual machine running a pristine
XP home SP2. No Python was previously installed.
Steps to reproduce:
1. Install Python 3.2.1 MSI from http://www.python.org/download/releases/3.2.1/
2. Run IDLE from
Eli Bendersky eli...@gmail.com added the comment:
Am I missing something, or is there no explicit command to kill the subprocess
on Windows in PyShell.py
The kill_subprocess method (which does get invoked) of ModifiedInterpreter is:
def kill_subprocess(self):
try:
Ned Deily n...@acm.org added the comment:
Doesn't unix_terminate() also get called on Windows? If so, what does
os.kill() do on Windows? The docs for os.kill say New in version 3.2: Windows
support. Perhaps this was being skipped before and now has some negative
effect?
--
Eli Bendersky eli...@gmail.com added the comment:
Indeed, unix_terminate is invoked on Windows, and since Windows now has
os.kill it runs. However, it appears that the actual os.kill call throws
OSError, saying:
[Error 87] The parameter is incorrect
--
Eli Bendersky eli...@gmail.com added the comment:
Here's a simple reproducer for the same problem, without the context of IDLE.
As far as I understand, what IDLE's spawn and then kill process are doing is:
import os
from signal import SIGTERM
pid = os.spawnv(os.P_NOWAIT, notepad.exe,
Georg Brandl ge...@python.org added the comment:
Hmm, the docs say Any other value for sig will cause the process to be
unconditionally killed by the TerminateProcess API [...]
What happens if you try to use other signals (like signal.SIGKILL) instead of
SIGTERM?
--
Georg Brandl ge...@python.org added the comment:
The other question is if it is an access control problem.
win32_kill tries to open the process with PROCESS_ALL_ACCESS, while IMO
PROCESS_TERMINATE would suffice.
--
___
Python tracker
Eli Bendersky eli...@gmail.com added the comment:
Georg, I'm now debugging into win32_kill, and it's an error in OpenProcess, so
this *could* be a security issue.
The process is started with _spawnv, so maybe this causes problems opening it
with OpenProcess later.
--
Eli Bendersky eli...@gmail.com added the comment:
According to
http://msdn.microsoft.com/en-us/library/7zt1y878%28v=vs.80%29.aspx, on Windows
_spawnv in async mode (P_NOWAIT) returns the process _handle_, not the process
ID.
win32_kill uses OpenProcess, passing it pid to obtain the handle,
Georg Brandl ge...@python.org added the comment:
Hmm, on the other hand there may be valid use cases for using os.kill() with a
PID. Argh.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
Eli Bendersky eli...@gmail.com added the comment:
I don't think there's a problem with os.spawnv and os.kill - they do what their
docs describe.
IMHO, the solution should be to change IDLE so that it uses subprocess.Popen
for both starting and killing the child process.
--
Terry J. Reedy tjre...@udel.edu added the comment:
Eli, nice detective work. What I understand is that there was a latent
platform-dependent buglet that presumably got exposed by a recent change in
process handling, as Ned suggested.
idlelib/PyShell.py, class
Eli Bendersky eli...@gmail.com added the comment:
Terry,
What still bugs me is that it isn't clear what change from 3.2 to 3.2.1 caused
this problem to manifest.
Also, I'm not sure why you mention the sockets vs. pipes issue.
--
___
Python tracker
Eli Bendersky eli...@gmail.com added the comment:
Is the problem happening only on 64-bit Windows, or 32-bit as well?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
___
Qiang Sun sunqi...@gmail.com added the comment:
I can reproduce this in 32-bit Windows XP Pro. SP3
--
nosy: +sunqiang
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
___
Terry J. Reedy tjre...@udel.edu added the comment:
Good question.
Peter, you said Vista x64. Are you running 32 or 64 bit Python?
My system with the apparently irreversible problem is 32 bit xp home.
I am reluctant to test on my daughter's 64 bit laptop as I do not know that I
would be able to
Terry J. Reedy tjre...@udel.edu added the comment:
This nasty bug really can cause severe problems. If a zombie process ran a
tkinter (tk) window, then attempting to logout/restart/shutdown eventually
brings up a window I have never seen before: End Process -- EmbeddedMenuWindow.
The message
Terry J. Reedy tjre...@udel.edu added the comment:
Restart is not required to create a zombie. Just start IDLE and quit, and the
second, user process does not disappear.
Reverting completely does not seem possible. I first just ran the 3.2 installer
and it did not complain, that I noticed,
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
___
___
Python-bugs-list
Aneesh aneeshb...@gmail.com added the comment:
We are also noticed same issue and reverted to Python 3.1. Whenever we run a
script, two new pythonw.exe process is started and it is really irritating to
see all in Windows Task Manager.
Last day I killed around 14 Pythonw.exe to clean up
Ned Deily n...@acm.org added the comment:
This appears to be a Windows-only issue; I'm not able to readily reproduce it
on either Linux or OS X. Taking a quick look at diffs between 3.2 and 3.2.1,
there aren't a lot of changes in IDLE (Lib/idlelib) and nothing obviously
related. There are a
Martin v. Löwis mar...@v.loewis.de added the comment:
FWIW, it only happens with IDLE; python.exe seems to terminate fine when done.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
Martin v. Löwis mar...@v.loewis.de added the comment:
Terry, please don't overreact. Nobody has noticed it during the *long* rc
period of 3.2.1, so it can't be that bad. Actually, I *did* notice, but didn't
have the time to submit a bug report.
--
priority: critical - high
Terry J. Reedy tjre...@udel.edu added the comment:
I just 'upgraded' to 3.2.1 on my XP machine and I see the same with F5-run,
which restarts before running the saved file. This appears to be a nasty
regression from 3.2.0 that should have been a release blocker if caught
earlier. I believe it
Changes by Georg Brandl ge...@python.org:
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12540
___
___
Python-bugs-list mailing
New submission from Peter Caven pca...@gmail.com:
On Windows Vista (x64) the IDLE Restart Shell command leaves a pythonw.exe
process running each time that the command is used.
Observed in Python 3.2.1 release and RC2.
--
components: IDLE
messages: 140179
nosy: Peter.Caven
priority:
39 matches
Mail list logo
