Kurt B. Kaiser wrote:
One thing you can try is to turn on the tracing built into IDLE's rpc.py:Did that.
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 :-)
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, andNo I mean worse than that: the windows are not repainted anymore (this means the TK thread is blocked).
that you can't restart the shell from the Shell menu.
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>
As I stated before, it tends to happen when typing quickly (arrow keys last time).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?
I'm currently using KDE (because I'm too lazy to get fvwm2 configured to my tastes),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 used to use ion a lot while in programming-intensive periods of my life.
Did that before killing the subprocess.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.
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
_______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
