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:

http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325

.. 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?

Robert


--------------

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


//

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

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

class CAllowThreads {
public:
    PyThreadState *_save; \
    CAllowThreads() {
            _save = PyEval_SaveThread();
    }
    ~CAllowThreads() {
        PyEval_RestoreThread(_save);
    }
};

PyObject* PyListView_GetSubItemRect(
    HWND hwndLV,
    int iItem,
    int iSubItem,
    int code
//    LPRECT lpRect
)
{
    RECT r;
    {
      CAllowThreads _t;
      ListView_GetSubItemRect(
        hwndLV,
        iItem,
        iSubItem,
        code,
        &r );
    }
    return Py_BuildValue("iiii",
r.left,r.top,r.right,r.bottom);

}

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

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

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;
   
if(!PyArg_ParseTuple(args,"i(iiiii(ii)):ToolTipRelayMsg",
                         &hwTT,

&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
                         &msg.pt, ((int*)&msg.pt)+1) )
        return NULL;

    
    {
      CAllowThreads _t;
      SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
    }

    Py_INCREF( Py_None );
    return Py_None;
}

---

"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):

self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))

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

    if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
    result = (int )GetStringAddr((char const *)arg0);
    resultobj = PyInt_FromLong((long)result);
    return resultobj;
} 

Logged In: YES 
user_id=21627

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.

Logged In: YES 
user_id=972995

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
---------------------------
OK   
---------------------------
"""

"""
AppName: app.exe	 AppVer: 2.7.0.0	 ModName: python23.dll
ModVer: 0.0.0.0	 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
---------------------------
OK   
---------------------------
"""

"""
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
information. 
---------------------------
OK   
---------------------------
"""
=======================================
(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?

Logged In: YES 
user_id=972995

Indications point more to a "dual core" problem in Pythonwin
=> Bug 1442426 in sf pywin32 project.

Logged In: YES 
user_id=21627

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").