How to find cause for Python/Pythonwin crash only on Dual Core Machines ?

[Larry Bates]

robert wrote:
> 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 specific 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;
> }

I've run on Dual 1.7, 2.4Ghz Xeon machines and a hyperthreaded
3.0Ghz machine for several years with no problems.  I don't think
there is an inherent problem.

-Larry Bates