Right now PythonCmd is using the Tcl interpreter stored in self->interp, but this is unsafe and since it is a Tcl_CmdProc it already receives the Tcl interpreter as a parameter. Using the interpreter in self->interp is unsafe because Python might deallocate this TkappObject and then PythonCmd could be invoked later, and using the interpreter given to the Tcl_CmdProc is guaranteed to be safe by Tcl. To reproduce this I needed a debug build and also needed to run the example below in the interpreter: >>> import tkFileDialog >>> tkFileDialog.askdirectory() # here I both windows, then: >>> Segmentation fault There are other ways to reproduce this but I can't remember them offhand, I know there are other ways because I've hit this same problem in another python <-> tcl bridge by doing something else. The patch could be expanded to remove the use of "self" in PythonCmd_Clientdata, but given another wish I have -- to move to Tcl_CreateObjCommand -- self would be needed again.
Another way to reproduce it (tested using debug build): Python 2.7a0 (trunk:69375:69376M, Feb 6 2009, 20:27:09) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> Tkinter.Tk() <Tkinter.Tk instance at 0xb79c8edc> >>> Tkinter.Tk() <Tkinter.Tk instance at 0xb79cb06c> # close both windows now, get a segfault
I will be committing this but I'm afraid a test won't be added for it. Several people told me that creating multiple tcl interpreters (even if only one is active at some point) is problematic, specially in older tcl versions. So if someone can find another way to reproduce the problem you are welcome to add a test. Ideally it would let the only tcl interpreter created still alive (although as I see this bug you will only hit it if a Tkapp is dealloced and then a callback created through Python is invoked), otherwise the other existing tests will suffer.
