Repository navigation
2.6.1 breaks many applications that embed Python on Windows #48816
Description
| BPO | 4566 |
|---|---|
| Nosy | @loewis, @mhammond, @tiran |
| Files |
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:
assignee = 'https://github.com/mhammond'
closed_at = <Date 2009-01-27.23:52:46.076>
created_at = <Date 2008-12-06.15:28:53.646>
labels = ['type-bug', 'OS-windows']
title = '2.6.1 breaks many applications that embed Python on Windows'
updated_at = <Date 2012-05-21.12:59:41.048>
user = 'https://bugs.python.org/craigh'bugs.python.org fields:
activity = <Date 2012-05-21.12:59:41.048>
actor = 'shooshx'
assignee = 'mhammond'
closed = True
closed_date = <Date 2009-01-27.23:52:46.076>
closer = 'mhammond'
components = ['Windows']
creation = <Date 2008-12-06.15:28:53.646>
creator = 'craigh'
dependencies = []
files = ['12249', '12250', '12549']
hgrepos = []
issue_num = 4566
keywords = ['patch', 'needs review']
message_count = 29.0
messages = ['77133', '77136', '77142', '77181', '77183', '77211', '77217', '77232', '78732', '78751', '78752', '78755', '78757', '78762', '78765', '78778', '78779', '78811', '78819', '78839', '78890', '79458', '79491', '80116', '80462', '80675', '80680', '88016', '161272']
nosy_count = 11.0
nosy_names = ['loewis', 'mhammond', 'ggenellina', 'christian.heimes', 'schmir', 'craigh', 'johnshue', 'rantanen', 'SandyBarbour', 'chrisyco', 'shooshx']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue4566'
versions = ['Python 2.6']
Activity
craigh commentedon Jan 2, 2009
I took a look at this with the debugger, as Mark recommended. The CRT's
DLLMain is called _CRTDLL_INIT, that in turn calls __CRTDLL_INIT.
__CRTDLL_INIT calls another function, _check_manifest.
_check_manifest calls an SxS function called FindActCtxSectionString.
It's looking for a string called "msvcr90.dll" in the
ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION section of the process's
activation context (activation contexts are data structures used by
SxS). That call fails (_check_manifest doesn't call GetLastError or
anything, it just returns FALSE right there). There's a comment there
that says:
/* no activation context used to load CRT DLL, means no manifest present
in the process */
What's bizarre is that python26.dll successfully loaded msvcr90.dll (the
global one from WinSxS), so it must have passed _check_manifest. It
seems like the activation context consists of the DLL's manifest
(_socket.pyd's in this case) and the exe's manifest, but no other ones,
regardless of what other libraries have been loaded. The documentation
doesn't seem to explain the interaction between manifests in different
modules. It's also annoying that this restriction (the _check_manifest
call) is completely artificial.
I don't know if any of this information is useful (I'm only
superficially familiar with activation contexts and the functions to
manipulate them). The code is all in crtlib.c (in the CRT source) if
someone else wants to take a look.
mhammond commentedon Jan 2, 2009
I've hacked together something that fixes the problem. I'm working on
making it a real patch, but the basis is:
In DllMain (dl_nt.c), we call:
case DLL_PROCESS_ATTACH:
GetCurrentActCtx(&PyWin_DLLhActivationContext);
AddRefActCtx(PyWin_DLLhActivationContext);
case DLL_PROCESS_DETACH:
ReleaseActCtx(PyWin_DLLhActivationContext);
(where PyWin_DLLhActivationContext is a module level HANDLE global)
The LoadLibraryEx (in dynload_win.c) changes to:
ActivateActCtx(PyWin_DLLhActivationContext, &cookie);
/* XXX This call doesn't exist in Windows CE */
hDLL = LoadLibraryEx(... as currently ...);
DeactivateActCtx(0, cookie);
This makes the "import socket" test case work for me. I'm not sure what
the impact will be should the .pyd file reference other assemblies.
Also, the calls above all need to move to function pointer calls as the
functions only exist on Vista and later (hence the slight delay in
making a real patch)
mhammond commentedon Jan 2, 2009
Attaching a patch which works for me against python 2.6. Only ever
tested on Vista (ie, where the function pointers etc all load)
mhammond commentedon Jan 2, 2009
Attaching a new patch with some typos in the comments corrected. While
I'm here, I also meant to mention (again!):
No need to remove the the assembly from the sxs cache - the test
"fails correctly" with VS2009 installed. FWIW, I compiled test.c from
the command line with:
% cl /I {pypath}\include /I {pypath}\PC /DDEBUG /D_DEBUG /MTd test.c
/LINK {pypath}\pcbuild\python26_d.lib
It appears the sxscache and the "gac" are indeed different things,
although at least one MS page refers to the sxscache as the "native
assembly cache" <wink/sigh>
craigh commentedon Jan 2, 2009
I haven't been able to try this patch myself yet, but I see a potential
problem: the "cookie" variable is declared as a DWORD, while
ActivateActCtx expects a ULONG_PTR. DWORD and ULONG_PTR are only the
same thing in 32-bit Windows.
Also, where are you seeing that these SxS functions are "Vista or
later"? My XP kernel32.dll has all of them. MSDN says they're XP or Vista.
craigh commentedon Jan 2, 2009
The patch works fine on my system (32-bit XP). Also I verified in
Process Explorer that there's only one instance of msvcr90.dll loaded.
loewis commentedon Jan 2, 2009
I'm not sure whether the license allows us to do so.
mhammond commentedon Jan 2, 2009
Uploading a corrected patch; some old docs I saw said DWORD, and I
obviously neglected to fix every spot I used that, and I've changed
'Vista' to 'XP' in the patch comments.
rantanen commentedon Jan 9, 2009
We encountered a problem that Windows installer created with 2.5.2 could
not be installed with 2.6.1 as executing the post-installer script
fails. More details about the reason can be found from
http://code.google.com/p/robotframework/issues/detail?id=196. Is the
problem related to this issue or should I create new issue about that. I
can also provide simple project that could be used to test this out.
loewis commentedon Jan 9, 2009
You should assume that it is not related.
That would be necessary.
SandyBarbour commentedon Jan 18, 2009
Over 3 years ago I wrote a plugin for the Xplane Flight Simulator.
This uses a SDK that Ben Supnik and myself created 6 years ago.
Our plugins are DLL's that our plugin manager DLL loads at run time.
The plugin embeds python and allows python scripts to be run from within
Xplane.
This has worked fine with python 2.3.x, 2.4.x, 2.5.x and 2.6.0.
I see the same problem as described here when using 2.6.1 with the
ctypes, socket libraries etc.
This also affects PyOpenGL as it uses ctypes.
I applied the patch that Mark posted and rebuilt python26.dll.
I tested this on Windows XP and Windows 7 Beta.
With the patched python26.dll my scripts now load properly.
The script that uses PyOpenGL also works fine now.
I thought that this feedback may be useful.
loewis commentedon Jan 24, 2009
Mark, the patch is fine, please apply. Great work!
mhammond commentedon Jan 27, 2009
ack - I mis-clicked and accidentally removed message78811 and can't see
how to reinstate it. The message isn't critical, but I'm sorry about that!
mhammond commentedon Jan 27, 2009
Checked in to the trunk as as r69038 and svnmerge'd:
chrisyco commentedon May 18, 2009
After some Googling, I found a possible solution:
http://lists.wxwidgets.org/pipermail/wxpython-users/2008-November/081981.html
shooshx commentedon May 21, 2012
For some reason this patch is disabled with #ifdefs when Py_ENABLE_SHARED is not defined.
I'm compiling python as a static lib and have unresolved externals for both these functions: _Py_ActivateActCtx, _Py_DeactivateActCtx