This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: A (treaded) Python crash only on dual core machines
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: kxroberto, loewis
Priority: normal Keywords:

Created on 2006-03-02 17:17 by kxroberto, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg27654 - (view) Author: kxroberto (kxroberto) Date: 2006-03-02 17:17
There is a strange freeze/crash only on dual core machines:

I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.

Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.

I found no hints other than:

.. both discussions remaining in uncertainty.

Are there (known) problems with Python/Pythonwin
specifically for dual core's  (py2.3.5 / pywin203) ?

What could I do to find the problem?



PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its


#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"

                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
    return TRUE;

class CAllowThreads {
    PyThreadState *_save; \
    CAllowThreads() {
            _save = PyEval_SaveThread();
    ~CAllowThreads() {

PyObject* PyListView_GetSubItemRect(
    HWND hwndLV,
    int iItem,
    int iSubItem,
    int code
//    LPRECT lpRect
    RECT r;
      CAllowThreads _t;
        &r );
    return Py_BuildValue("iiii",


int GetStringAddr(const char* s) {
    return (int)s;

int PlaySoundResource(int resid, HMODULE hmod)
    CAllowThreads _t;
    return PlaySound(MAKEINTRESOURCE(resid), hmod,

int PlaySoundFile(const char* fname, int flag)
    CAllowThreads _t;
    return PlaySound(fname, NULL, flag);

PyObject* py_ToolTipRelayMsg(  PyObject* self,
PyObject* args )
    MSG msg;
    HWND hwTT;

                         &, ((int*)& )
        return NULL;

      CAllowThreads _t;

    Py_INCREF( Py_None );
    return Py_None;


"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):,iPane,extension.GetStringAddr(text))

--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
    PyObject *resultobj;
    char *arg0 ;
    int result ;

*)"s:GetStringAddr",&arg0)) return NULL;
    result = (int )GetStringAddr((char const *)arg0);
    resultobj = PyInt_FromLong((long)result);
    return resultobj;
msg27655 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-03-03 17:40
Logged In: YES 

You don't provide complete source code for anybody to try to reproduce this 
problem. My guess is that you are calling into the Python runtime without 
holding the global interpreter lock. This can easily create all sorts of problems.

Never release the GIL unless you are absolutely certain that no Python code will 
be executed; neither directly nor indirectly. Don't invoke Python API in a thread 
(e.g. while processing a Windows message) without acquiring the GIL first.
msg27656 - (view) Author: kxroberto (kxroberto) Date: 2006-03-08 11:31
Logged In: YES 

Find no indications, that it is a GIL problem. Whenever
there was a GIL problem in past, I quickly got problems on
any machine, not specifically only on dual cores.
(The thread-state handling of above short extension code is
done in the same style as in PythonWin for critical
functions, which might come back as new messages in the
message handler. This should be ok. Otherwise there is only
normal Python/Pythonwin code).

The python part of the soft is too big, and I didn't manage
to isolate the problem further as I have only a handful of
user reports like this:
Yes here is one popup window.

app.exe - Application Error
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program

AppName: app.exe	 AppVer:	 ModName: python23.dll
ModVer:	 Offset: 00084ade

Followed by an application error window.

app.exe - Application Error
The instruction at "0x73dd11c7" referenced memory at
"0x00000004". The memory could not be "read". 
Click on OK to terminate the program

Here is another error just now after latest upgrade

Microsoft Visual C++ Runtime Library
Runtime Error!

Program: C:\bin\app.exe

 This application has requested the Runtime to terminate it
in an unusual way.
Please contact the application's support team for more
(The memory errors above are within mfc42.dll)

I use a maybe questionable practice (which I use in order to
smoothen the GUI ):  I start normal Python threads, which
use themselfs win32-functions. I guess this is ok, as
windows GUI functions are considered to be thread-safe.

A simplified example:

thread.start_new(win32ui.MessageBox, 'test')

Guess, this is ok?

msg27657 - (view) Author: kxroberto (kxroberto) Date: 2006-03-08 15:41
Logged In: YES 

Indications point more to a "dual core" problem in Pythonwin
=> Bug 1442426 in sf pywin32 project.
msg27658 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-03-09 01:13
Logged In: YES 

Well, this bug here is clearly something different. An
attempt to access 0x00000004 very obviously is a null
pointer access, at a structure offset at offset 4. At offset
4, if this is a Python object (which it might not be), is
the ob_type field of an object. So it might be that somebody
tries to find out the Python type of a null pointer (which
ought to crash).

This is different from 1442426, which apparently is not a
null-pointer access.

Without any kind of backtrace, it is very hard to guess what
the cause of this null-pointer access might be - it could be
everywhere (including Python, PythonWin, and,
last-but-not-least, your code).

So I'm closing this as "unreproducable" (for which SF only
has "works for me").
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42969
2006-03-02 17:17:54kxrobertocreate