When I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears.

Terminal reports a "Segmentation fault" upon the crash.

My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable.  

IDLE also appears stable until I select this option.

The Python crash log is attached.

Please, can anyone suggest what may be causing this problem?  Thank you.

A similar problem arises with WinXP when trying to configure IDLE via the "Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no effect. However when closing the window by clicking on either the window close button (top right 'X') or the 'Cancel' button, several bahaviors are observed depending on how many times one has clicked on the 'Ok' and/or 'Cancel' buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is resumed and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 -> WinXP SP2

Erratum:

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors are
observed depending on how many times one has clicked on the 'Ok' and/or
---->'Apply'<---- buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

Bumping up the priority so this doesn't get lost.  My guess is that IDLE is tickling some problem with the TkInter bindings.

It seems to be caused by Tcl/Tk, I cannot reproduce this with the system version of Tk

This is on 10.4.8/intel, with python 2.5.1rc1. I don't think the change in python version fixes this issue.

Mick: could you please test what happens when you temporarily move /Library/Frameworks/Tcl.framework and /Library/Frameworks/Tk.framework to another folder.

OK... I followed your advice Ronald (moved the Tcl and Tk frameworks out of Library), and it worked!  IDLE no longer crashes! Thank you so much!

With the frameworks moved, it apparently reverts to Tcl/Tk 8.4.7

The only oddity is that there is a _very_ long delay (beachball) when opening preferences / configure IDLE; but now that the font is legibly large, I doubt I shall need to go back there.

Thank you again,
Kind regards, Mick L

FYI, I managed to solve the issue (under WinXP) by clearing the .idlerc\config-main.cfg configuration file...

Cheers!

So, can this be closed or should we try to handle the two different
issues (bad .idlerc\config-main.cfg, wrong Tcl/Tk) in a better way?

Status should not be pending unless issue is assigned and a resolution 
is in progress.  Issue only reported on 2.5 as far as I can tell, let's 
see if it gets reported again for a later version of Python/Tk.  We 
appear to have a workaround for Windows, at least - remove config-
main.cfg and let IDLE recreate it.  Note that IDLE can't 'crash', it's 
pure Python - any crash would be in Python or Tcl/Tk. However, IDLE can 
raise an exception and exit.  If it's an IDLE failure, the traceback 
will be written to the console, so you have to start IDLE from the 
console to see it.

Also, it does sound like the Mac and XP issues are separate problems, 
so please reopen this bug and include a traceback if the failure is seen 
again.

My error, I was thinking of Debian's use of 'pending'.  On Sourceforge, 
setting an issue to pending would cause it to automatically close after 
awhile if there was not further response.  On this Tracker, we would use 
that status the same way, but I believe we have to close it manually 
after awhile?