[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC

Andre Heider report at bugs.python.org
Tue Oct 14 15:35:43 CEST 2008


Andre Heider <a.heider at gom.com> added the comment:

Yes, i know that v2.5 doesn't officially support MSVC9. But the same
problem applies to MSVC8 and its CRT. But in contrast to MSVC9, the CRT8
redist is installed on almost every machine, because alot of software
installs it. But thats basically just luck ;)

Placing just a .manifest next to *.pyd won't work either. If you're
going this route, you have to put the 3 CRT DLLs there too (and thats
actually the approach mentioned here:
http://msdn.microsoft.com/en-us/library/ms235291.aspx)
Then you've got 2 cases:
1) The user does have the redist installed
or
2) He does not

for 1) The WinSXS installation has a higher priority and the local files
are ignored
for 2) The files next to the binaries are used (eg c:\python and
c:\python\DLLs)

Sounds fine, but the latter raises another issue: Now you have 2 copies
of the DLLs. Based on these 2 unique file names, windows decides to load
2 copies into memory, one for python.exe|dll and one for *.pyd. As you
might see, this gets very nasty because you have 2 different heaps now.
Allocating memory from the one instance and freeing it in the other
makes the whole process crash.

This issue doesn't stop here, here's another situation:
Python is compiled with MSVC9. A user has it and MSVC9 SP1 installed,
which has a newer CRT version. If he builds site-packages, these files
have an embedded manifest with another CRT version than the python
interpreter itself. Importing these packages loads a second copy of a
CRT into the processes memory, just like described above.

I don't know if or for what version this should be addressed for python.
I'm just saying that this was a huge issue the last days at the company
i work for.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________


More information about the Python-bugs-list mailing list