[PyKDE] PyQt4 random crashes under windows.

Giovanni Bajo rasky at develer.com
Tue Jan 23 09:30:22 GMT 2007


On 23/01/2007 9.14, V. Armando Sole wrote:

>> With that patch installed, the whole PyQt+Qt block should use *only* 
>> msvcr71.dll (you can verify it by inspecting the dependencies of the 
>> generated dynamic libraries). If that's the case, it surely means that 
>> this is *not* the problem causing a random crash.
> 
> If I run depends on almost any library I find dependences on msvcrt.dll 
> thru other libraries. For instance, for QtCore4.dll I get dependences on 
> msvcrt.dll thru ADVAPI32.DLL and WS2_32.DLL

That does not matter of course. Otherwise, you should recompile Windows to be 
able to use VS2003 on your project, and I heard that's pretty hard to do :) 
What you want to check is whether your Python extensions *directly* depend on 
MSVCRT.DLL, instead of MSVCRT71.DLL.

The problem is that MS got it wrong with the CRT runtime. They underestimated 
the fact that not every library is COM or export a pure Win32-only interface 
to users :)

In Python, you mostly *can* mixmatch different CRT versions between the Python 
core and the extensions. In fact, Python APIs are mostly CRT-agnostic, but 
there are of course a few exceptions (like PyFile_FromFile which gets a 
FILE*). If the extensions you write/use only limit themselves to the 
CRT-agnostic part of the Python API, they will work fine even with a different 
CRT version.

Remember also that *ALL* object allocation (both the PyObject_New and the 
PyMem_New families) are totally CRT-agnostic, because they all happen within 
the python.dll, so they all pull memory from the same heap; an extension which 
follows the official Python API never manually allocates or frees Python 
objects, but always do that with the proper APIs.

To the best of my understanding, current versions of PyQt/SIP *do* limit 
themselves to the CRT-agnostic part of the Python API. I believe this was not 
a design choice, but as I said we're speaking of a very large subset of the 
APIs, so it's actually easy to get this right by chance. Instead, it is 
*crucial* that PyQt and Qt are compiled with the *SAME* compiler, since Qt's 
API are absolutely *NOT* CRT-agnostic: it's very common that an application 
allocates an object (through "new") and the Qt code  destroys it (eg: all 
QWidgets children). So, basically, you can use whatever compiler you want for 
PyQt and Qt, but it has to be the same for both!

[Of course, it would be nice if Python was totally and officially CRT 
agnostic, so that users will have freedom to use whatever compiler they please 
for extensions. Python 3k is a step forward in this direction, since the 
planned rewriting of the I/O stack will not make use of the C file API 
(fopen() and friends) but directly use platform APIs (POSIX open(), or Win32 
CreateFile()).]
-- 
Giovanni Bajo




More information about the PyQt mailing list