[Idle-dev] IDLE freezing/hanging

Kurt B. Kaiser kbk at shore.net
Wed Feb 23 20:04:25 CET 2005


Grégoire Dooms <dooms at info.ucl.ac.be> writes:

> Me too.
> I use Debian unstable and Idle patched with Raphael Noam's
> enhancements (they are great I would love to see this merged).

This will happen fairly soon.  He has an enthusiatic following.

> I tried to debug the problem but am not aware of a way to attach a
> debugger to a python process (I would like to do it at a higher level
> than interpreter level with gdb).

There is a graphics version of gdb: ddd

http://www.gnu.org/software/ddd/ddd.html

> All I could do up to now is strace both processes and see one of them
> repeating a sequence of futex and select calls (this is normal I think)
>  while the other is blocked in a futex call.

OK, it may be that the subprocess is somehow blocked looking for input
from the GUI.  

> I tried to get that process out of the futex call by sending a signal
> but all signals I tried up to now made it exit (HUP and CHLD, if I
> remember correctly). The problem is not easily reproductible as it
> seems to occur at random. But I feel it could be related to rate of
> typing as I nearly always get it when typing on my laptop keyboard.

The blizzard of futex calls is due to polling the sockets.  That is
done by both the GUI and the subprocess (execution server).  The tricky
thing debugging IDLE is to do it amid all that activity.

If you can get to a point where you have something at least partially
reproducible, try running IDLE with the -n switch :

(cd ..../Lib/idlelib && ../../python ./PyShell.py -n) or idle -n,
depending on how your system is set up.  See if the problem goes away.

> I did not submit a bug as this is patched code and I never had a
> student annoyed by this bug.
> I'm willing to help trace and fix the bug if you can direct me in the
> right direction.

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 :-)

When IDLE freezes, I assume you mean that the GUI is unresponsive, and
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.

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 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.)

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.

-- 
KBK


More information about the IDLE-dev mailing list