Bugs item #1441884, was opened at 2006-03-02 18:17 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: A (treaded) Python crash only on dual core machines Initial Comment: 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; } ---------------------------------------------------------------------- >Comment By: Robert Kiendl (kxroberto) Date: 2006-03-08 12:31 Message: 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? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 18:40 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
