[Idle-dev] IDLE freezing/hanging

[Grégoire Dooms]

Kurt B. Kaiser wrote:

>One thing you can try is to turn on the tracing built into IDLE's 
>rpc.py:
>
>File / Open Module  : rpc
>
>In class RPCHandler and class RPCClient there are 'debugging'
>variables.  Set them to True and restart IDLE.  You'll now see
>extensive output in the command window.  Note that this output is an
>interleave of everything going on, and, as is typical of output from
>several threads, may be slightly out of sequence.  But there are
>sequence numbers associated with each rpc call to help you decode all
>that.  If that isn't enough, there are some print>>sys.__stderr__ 
>statements in rpc.py which are commented out.  You can turn them on to
>get a veritable blizzard of traces :-)
>
>  
>
Did that.
Here is the last lines before the hang-up:
#S SockThread localcall: ('CALL', ('exec', 'get_the_completion_list', 
('G2', 1), {}))
#S SockThread pollresponse:247:localcall:response:('OK', ([], []))
#S SockThread putmessage:247:
#S SockThread pollresponse:249:myseq:None
#S SockThread pollresponse:249:localcall:call:
#S SockThread localcall: ('CALL', ('exec', 'get_the_calltip', 
('PropertyVertex',), {}))
#S SockThread pollresponse:249:localcall:response:('OK', '')
#S SockThread putmessage:249:
#S SockThread pollresponse:251:myseq:None
#S SockThread pollresponse:251:localcall:call:
#S SockThread localcall: ('CALL', ('exec', 'get_the_calltip', 
('__getitem__',), {}))
#S SockThread pollresponse:251:localcall:response:('OK', '')
#S SockThread putmessage:251:

>When IDLE freezes, I assume you mean that the GUI is unresponsive, and
>that you can't restart the shell from the Shell menu.  
>
No I mean worse than that: the windows are not repainted anymore (this 
means the TK thread is blocked).

>If so, try
>this: kill the subprocess with 
>'kill -KILL xxxxx'.  The subprocess is the one with '8833' in its
>command line (ps ax).
>  
>
>IDLE should then spawn a fresh subprocess and you should be able to
>continue without losing any of your work.
>
>  
>
Nope, that process (zombie) then shows up in ps as:
[python2.3] <defunct>

>If it doesn't, that points to a problem with Tk.  Does it happen while
>you're typing quickly, or will it freeze while you're having lunch?
>
>  
>
As I stated before, it tends to happen when typing quickly (arrow keys 
last time).

>I must say: I've been using IDLE for years, on W98, W2K, WXP, RH6.2,
>Arch Linux, and OpenBSD.  I've never had IDLE freeze on me unless I
>made a coding error while working on IDLE itself.  Then I see a
>traceback in the command window.
>
>I have had X crash.  And even a couple of emacs hangs.  These things
>seem to happen once in a blue moon when I'm using Gnome on Arch (which
>is pretty bleeding edge).  What's your desktop/window manager?
>
>(I mostly use Ion, it works extremely well with IDLE because Ion uses
>non-overlapping panes and each pane can contain multiple tabbed IDLE
>windows which can be dragged/dropped into different panes.  After you
>use Ion for awhile you realize that overlapping windows are just an
>awful design choice made at Xerox PARC lo those many years ago.  It's
>also super lightweight and stable.)
>
>  
>
I'm currently using KDE (because I'm too lazy to get fvwm2 configured to 
my tastes),
I used to use ion a lot while in programming-intensive periods of my life.

>IDLE is written in pure Python.  So if the 'freeze' isn't due to some
>hitherto undetected GUI/subprocess interaction deadlock (which can be
>resolved w/o losing work by killing the subprocess), then there is an
>issue in the C code implementing Python or Tk.  Hardware seems to be
>ruled out because all of you are having problems on Debian Sid.
>
>And the way to debug that is to attach gdb to it.  It won't be pretty.
>The subprocess has two threads: one executing user code, and one
>minding the sockets. The GUI has one thread which executes the Tk
>event loop, with polling implemented using after() calls.  Additional
>threads are created as necessary for callbacks from the subprocess.
>
>  
>
Did that before killing the subprocess.
In that subprocess, there were three threads all in a select call, one 
of them had some tk related calls in the stack.

After killing the subprocess I attached gdb to the main python process 
and got this out of it:
(gdb) info threads
  2 Thread 1092189136 (LWP 5748)  0x401375d7 in select () from 
/lib/tls/libc.so.6
  1 Thread 1075429504 (LWP 5747)  0x400310d5 in 
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) thread 2
[Switching to thread 2 (Thread 1092189136 (LWP 5748))]#0  0x401375d7 in 
select () from /lib/tls/libc.so.6
(gdb) info stack
#0  0x401375d7 in select () from /lib/tls/libc.so.6
#1  0x408a2388 in Tcl_WaitForEvent () from /usr/lib/libtcl8.4.so.0
#2  0x4002e964 in start_thread () from /lib/tls/libpthread.so.0
(gdb) thread 1
[Switching to thread 1 (Thread 1075429504 (LWP 5747))]#0  0x400310d5 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
(gdb) info stack
#0  0x400310d5 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/tls/libpthread.so.0
#1  0x408a1570 in Tcl_ConditionWait () from /usr/lib/libtcl8.4.so.0
#2  0x408a2115 in Tcl_WaitForEvent () from /usr/lib/libtcl8.4.so.0
#3  0x4087e35c in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so.0
#4  0x4047de51 in init_tkinter () from 
/usr/lib/python2.3/lib-dynload/_tkinter.so
#5  0x080fde1a in PyCFunction_Call ()
#6  0x080ab824 in PyEval_CallObjectWithKeywords ()
#7  0x080a9bde in Py_MakePendingCalls ()
#8  0x080aa76c in PyEval_EvalCodeEx ()
#9  0x080ab8d9 in PyEval_CallObjectWithKeywords ()
#10 0x080ab71c in PyEval_CallObjectWithKeywords ()
#11 0x080a9bde in Py_MakePendingCalls ()
#12 0x080ab95d in PyEval_CallObjectWithKeywords ()
#13 0x080ab71c in PyEval_CallObjectWithKeywords ()
#14 0x080a9bde in Py_MakePendingCalls ()
#15 0x080aa76c in PyEval_EvalCodeEx ()
#16 0x080acf69 in PyEval_EvalCode ()
#17 0x080d90db in PyRun_FileExFlags ()
#18 0x080d888f in PyRun_SimpleFileExFlags ()
#19 0x08054e95 in Py_Main ()
#20 0x080549eb in main ()

I believe this could be related to a bug in tk8.4 (8.4.7-1) I'll upgrade 
now to 8.4.9-1 and see if the bug disappears.
I'll report again next time the bug appears.
If you have any info meanwhile...

Regards,
--
Grégoire Dooms