idle BUG

[Mike Clarkson]

On Thu, 14 Jun 2001 22:24:47 -0400, "Tim Peters" <tim.one at home.com>
wrote:

>[Robin Becker]
>> I think this must be a bug in Tkinter, but since no one ever responds I
>> thought I'd whine about idle instead.
>
>See
>
>http://sf.net/tracker/?group_id=5470&atid=105470&func=detail&aid=216289

That it.  It also happens on Win98.

>> I run python2.1 Win95 OSR2.
>> Start a command window
>> run python idle.py
>>
>> Kill the idle window using the mouse (click on the x). In some unknown
>> percentage of cases (like 50%) the process hangs and doesn't return to
>> the command window.
>>
>> The hung process is very destructive and makes it impossible to reboot
>> the machine properly. This bug has been present for a very long time
>> and I'm fed up with it.
>
>Use pythonw instead.  Then it doesn't hang.  Nobody knows how to fix it, or
>even what causes it (follow the link).

Unfortunately that's not a complete solution: I've seen this with
frozen Tkinter applications too (Python 2.1 Tk 8..3.3 Win98).

>> It's clearly some kind of race between python and Tcl/Tk.

I don't thiink it's a race condition with Tk. If you modify idle
before invoking the mainloop with

	root.tk.eval('tk appname Idle')
	root.tk.eval('package require dde')
	root.tk.eval('dde servername Idle')

you can see that the 'hung' process so longer has a Tcl
interpreter alive, although the Python process is still alive and
consuming  CPU.

>Fredrik Lundh has provoked the same problems with pure Tcl/Tk apps run from
>a wish shell -- no Python components involved.  That is, there's no reason
>to believe Tkinter or Python have anything to do with this.

I've never seen this in the last five years of Tk apps or embedded Tk
apps. There's every reason to believe that it's the way Tk is being
compiled invoked or closed by Python.  The difference between 
pythonw and python.exe points to a stdin/stdout issue.

>> The problem doesn't occur on win2k so I guess there's some
>> difference between the run times that helps.

Not necessarily - nt and win95 differ hugely in that command.com is 16
bit and cmd.exe is 32. The likely difference could also be something
to do with stdin and stdout, which are also treated differently.

>Win9x suffers many flaky behaviors related to consoles and processes.
>pythonw appears to avoid the hangup problems simply by getting the console
>window out of the equation.  Without MS's source code at hand, I doubt we'll
>ever get a deeper understanding than that.

It's not necessarily a flaky behaviour. Harder than getting MS source
code is finding someone who understands MSVC's compile and link time
options.  Rather than assume it's bugs in M$'s code (still present in
Win98), we should make sure that it's not Python's fault.  From my
memory of earlier experiences with the MSVC makefile.vc for Tk,
the -DCONSOLE and -subsystem:console compiler and linker flags
took a lot of trial and error to get right for wish.

Tim, I know you're very busy these days (learning to sketch? :-), but
could  you examine the MSVC compile and link flags with a microscope
for similarities and differences between _tkinter.c and tkappinit.c
and tkAppinit.c for wish.

Robin, another thing you might try, is after the idle .mainloop()
call, do a 
	root.tk.eval('tk_messageBox ...')
call to make sure you are exiting the mainloop, and maybe look
to see what top level windows are around with 
	root.tk.eval('tk_messageBox  [winfo child .] ...')
I'm going to try
	root.tk.eval('catch {close stdin; close stdout}')


The problem is serious as you can kill the winoldap but the python.exe
is unkillable, an thus inhibits shutdown.*  It probably means that
anyone who distributes frozen applications may be generating
unkillable python processes. It would be nice to kill this problem.

PS: The windows process monitor AMD (http://atm.idic.caos.it) shows
the python.exe in a T state.

PPS: Neither Python nor Tk handle windows 
WM_QUERYENDSESSION and WM_ENDSESSION events - another topic.