Allow pydoc to work with XP Themes (.manifest file)

[26af53de-f307-4809-a4a7-9d50203b0a97]

BPO	997284
Nosy	@loewis
Files	pydoc.py.diff test.py: Causes Null tstate fatal error during exit

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['library'] title = 'Allow pydoc to work with XP Themes (.manifest file)' updated_at = user = 'https://bugs.python.org/glchapman' ``` bugs.python.org fields: ```python activity = actor = 'glchapman' assignee = 'none' closed = True closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'glchapman' dependencies = [] files = ['6111', '6112'] hgrepos = [] issue_num = 997284 keywords = ['patch'] message_count = 5.0 messages = ['46452', '46453', '46454', '46455', '46456'] nosy_count = 2.0 nosy_names = ['loewis', 'glchapman'] pr_nums = [] priority = 'normal' resolution = 'accepted' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue997284' versions = ['Python 2.3'] ```

[26af53de-f307-4809-a4a7-9d50203b0a97]

In Python 2.3.4, if you run pydoc -g under Windows XP when one of the special XP theme manifest files has been defined for python.exe or pythonw.exe, pydoc will cause an access violation when it closes. One solution is obviously to get rid of the manifest files, but wxPython installs them by default and apps written with it work without a problem. So it would be nice if pydoc would also work, and it turns out it didn't take a big change. Attached is a patch which fixes the problem (at least on my system). I noticed that idle did not have the access violation problem, and so copied what it does in PyShell.main.

It might be better to introduce a more general fix for Tkinter. The problem seems to be that Uxtheme.dll frees up some global data before all the windows have called CloseThemeData (at app shutdown). The AV seems to happen when a call to CloseThemeData (presumably in response to a WM_DESTROY message) passes a bad pointer to RtlEnterCriticalSection. Anyway, it seems that if you get the window handles destroyed earlier in shutdown, the problem is fixed. Perhaps there is some way to provide the Tkinter module with an atexit handler which would destroy any existing widgets?

[61337411-43fc-4a9c-b8d5-4060aede66d0]

Logged In: YES user_id=21627

This is quite an obscure problem, so I added a comment an committed it as pydoc.py 1.86.8.3 and 1.97, NEWS 1.831.4.144.

[26af53de-f307-4809-a4a7-9d50203b0a97]

Logged In: YES user_id=86307

I admit the cause is obscure, but I think the problem will potentially affect most Tkinter programs (see for example, www.python.org/sf/774188 -- which links to a wiki article referring to crashes in Tkinter with manifest files present). I just tried pynche.pyw, redemo.py, wcgui.py, and wsgui.py (from the Tools branch) and they all crashed on exit (at the same location in kernel32, with the same attempt to read 0x00000028). This is with Python 2.3.4 under XP (I don't have access to an XP SP2 machine right now: I wonder if this has been fixed).

Anyway, I added the following to Tkinter, and the crashes went away (I don't usually use Tkinter, so this may not be the best way to accomplish this):

import atexit

def _tkAtExit():
    if _default_root is not None:
        _default_root.destroy()

atexit.register(_tkAtExit)

[61337411-43fc-4a9c-b8d5-4060aede66d0]

Logged In: YES user_id=21627

I'd still woud prefer if a "proper" patch would be found, i.e. one that doesn't cause a crash in response to WM_DESTROY. For that, one would have to understand why it crashes, and see whether it is Tk's fault - if so, Tk should be fixed. If it really is presumed to be a Windows bug/limitation, I'd like to see the KB article that acknowledges the problem, and apply the work-around suggested in the KB.

[26af53de-f307-4809-a4a7-9d50203b0a97]

Logged In: YES user_id=86307

I'm fairly sure the problem is that Tk is calling DestroyWindow (a User32 function) during handling of a DLL_PROCESS_DETACH; according to the documentation of DllMain this is unsupported and may cause access violations (only calls to Kernel32.dll routines are safe). The reason for the AV is presumably that uxtheme.dll gets DLL_PROCESS_DETACH first and frees its global data (I believe the AV only happens if DestroyWindow is called on windows which are, or have children which are, themed controls). I haven't built a debug version of the Tk dlls since I'm not actually sure what source base is used to produce them. However, if they are produced from the tktoolkit project on sourceforge, it appears DLL_PROCESS_DETACH results in a call to TkFinalize, which runs a set of exit handlers. It appears one of these is DeleteWindowsExitProc, which calls Tk_DestroyWindow on various windows. If various conditions are met, this will result in a call to XDestroyWindow, which may in turn call DestroyWindow.

Perhaps the answer is to reinstate the Py_AtExit registration of Tcl_Finalize. On windows, anyway, the problem noted in the comment in _tkinter.c still exists in Python 2.3.4. If you give a \<Destroy> handler to a window which is not destroyed by Python, it is apparently destroyed with the DLL cleanup code, triggering a Python fatal error for a NULL thread state (see the attached test.py, a hacked up wsgui which I've been using for testing). So anyway, some other fix is needed for the \<Destroy> handler problem, and it looks like Tcl_Finalize would run the Tk exit procs before the handling of DLL_PROCESS_DETACH.