Finally dug up the reason but unsure how to fix it.

Here's the trace. The format is `$TID: $FUNCTION [some of the args]'

0x1A34: Tkapp_Call(_object *, _object *)
0x1A34: PythonCmd(void *, Tcl_Interp *, int, const char * *) 0x000000000230f430 0x0000000002d297d0 "47566760dummy_handler" 0x0000000003a28580 "5" 0x0000000003a29140 "??" 0x0000000003a29140 "??"
0x1D7C: Tkapp_Call(_object *, _object *)
0x1D7C: PythonCmd(void *, Tcl_Interp *, int, const char * *) 0x000000000230f430 0x0000000002d297d0 "47566760dummy_handler" 0x0000000003a28580 "5" 0x0000000003a29140 "??" 0x0000000003a29140 "??"
0x1A34: PythonCmd(void *, Tcl_Interp *, int, const char * *) setting result
0x1A34: PythonCmd(void *, Tcl_Interp *, int, const char * *) exit: 0
TclStackFree: incorrect freePtr (0000000002BA6430 != 0000000002BA6A20). Call out of sequence?python_d.exe has triggered a breakpoint.


A second PythonCmd is started when the 1st one is still in progress, then the 1st one returns, the Tcl interpreter tries to unwind the topmost stack frame, and it's the wrong one.


Denying other PythonCmd is out of question (a nested cmd deadlocks). Waiting for them to finish, either (would wait for potentially unlimited time).

Look like the only way is to rearrange Tcl stack frames so that the right one is on top. (Since Tkinter's "interpreter calls" (sequences of Tcl calls done while holding the lock) are supposed to be independent from one another, it doesn't really matter which order the frames are in.)

I seriously doubt that's possible with just the public interface though.