22

My C++ application embeds the Python interpreter, but seems to be having some trouble when it shuts down. Right after the main window closes, I get a segmentation fault (this is Windows, but we'll call it a segmentation fault anyway). The stack trace is below:

#0 102AD580 tk85!Tk_MainWindow() (C:\Users\... 1.3\bin\Debug\lib\tk85.dll:??)
#1 103082DD tk85!XSetStipple() (C:\Users\... 1.3\bin\Debug\lib\tk85.dll:??)
#2 102214A3 ??() (C:\Users\...1.3\bin\Debug\lib\tk85.dll:??)
#3 10220000 ??() (??:??)
#4 00000000 ??() (??:??)

Where would I even begin to debug this problem? It seems to be reproducible.

ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152
Nathan Osman
  • 71,149
  • 71
  • 256
  • 361
  • 1
    I've got the same problem on a machine. We didn't consciously import `tkinter` or associated code. But removing `tk85.dll` stops the problem happening. – David Fraser Nov 23 '17 at 15:16
  • Is there some sample app, distributed with interpreter? If yes, does it crash? – Dmytro Ovdiienko May 28 '18 at 23:11
  • Do you have the source? what is XSetStipple trying to do? one way to bisect would be to creat an `atexit` handler and just put a breakpoint in it to see if this happens before or after teardown (use your handler to step up into the CRT at exit code and put the breakpoint at the start of that function so you can catch this before all handlers). some violent things happen during exit, like all but the main thread get killed, so it is possible this could be part of it. also possible some resource is getting freed and this function shouldn't be getting invoked. does tk have a shutdown path? – aaron Sep 04 '18 at 23:52
  • If you have Windows 10, then install WinDbg Preview from Windows store, and record a trace with Time-Travelling Debugging enabled. Then open this trace, and step backwards from the end until you see something familiar in the stack trace for the first time. Perhaps it would help you to understand how you got into trouble. Also, you can see the order of module unloading there. – stgatilov Jul 25 '19 at 17:49

1 Answers1

1

First, I let you know that I identified race conditions in Python's Tkinter when used with nonthreaded Tcl/Tk (Py2 is shipped with that) and proposed a fix. I'm not sure I fixed all the possible race conditions but I did fix all that I have run into.

Now, to be able to debug Tcl/Tk issues, you need to build Python with a debug version of Tcl/Tk and embed that. This should give you the ability to look into tk*.dll in debugger and see what's wrong.

  • Get the source code for your Python version and make the following changes:

    --- a/PCbuild/prepare_tcltk.bat
+++ b/PCbuild/prepare_tcltk.bat
@@ -46,10 +46,10 @@ rem if ERRORLEVEL 1 (echo Cannot locate python.exe on PATH or as PYTHON variable

 call "%PCBUILD%\get_externals.bat" --tkinter-src %ORG_SETTING%

-%MSBUILD% "%PCBUILD%\tcl.vcxproj" /p:Configuration=Release /p:Platform=Win32
-%MSBUILD% "%PCBUILD%\tk.vcxproj" /p:Configuration=Release /p:Platform=Win32
-%MSBUILD% "%PCBUILD%\tix.vcxproj" /p:Configuration=Release /p:Platform=Win32
+%MSBUILD% "%PCBUILD%\tcl.vcxproj" /p:Configuration=Debug /p:Platform=Win32
+%MSBUILD% "%PCBUILD%\tk.vcxproj" /p:Configuration=Debug /p:Platform=Win32
+%MSBUILD% "%PCBUILD%\tix.vcxproj" /p:Configuration=Debug /p:Platform=Win32

-%MSBUILD% "%PCBUILD%\tcl.vcxproj" /p:Configuration=Release /p:Platform=x64
-%MSBUILD% "%PCBUILD%\tk.vcxproj" /p:Configuration=Release /p:Platform=x64
-%MSBUILD% "%PCBUILD%\tix.vcxproj" /p:Configuration=Release /p:Platform=x64
+%MSBUILD% "%PCBUILD%\tcl.vcxproj" /p:Configuration=Debug /p:Platform=x64
+%MSBUILD% "%PCBUILD%\tk.vcxproj" /p:Configuration=Debug /p:Platform=x64
+%MSBUILD% "%PCBUILD%\tix.vcxproj" /p:Configuration=Debug /p:Platform=x64

  • run PCBuild\prepare_tcltk.bat from VS command prompt to download and build Tcl/Tk from source

  • Now build a debug Python as usual (PCBuild\readme.txt has the instructions).

ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152