pywin32-bugs Mailing List for Python for Windows Extensions (Page 69)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2006-11-22 16:44:08
|
Bugs item #1601247, was opened at 2006-11-22 10:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1601247&group_id=78018 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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ollie oldham (ooldham) Assigned to: Nobody/Anonymous (nobody) Summary: win32pdh.EnumObjectItems white lie Initial Comment: win32pdh.EnumObjectItems appears to lie sometimes. If EnumObjectItems is called from the "main" thread - no problem appears. However if EnumObjectItems is called from another thread, it may lie as to the existence of a process name. How to reproduce: start attached script (xxx.py). Use the menu option of: g. This will print a current list of processes. Now start another application of some kind, different than any process name that was in the above list. For instance, notepad or some other editor. Now hit g again. The process name will NOT appear. Now hit x. start xxx.py again. Now hit g. The process name will now appear... Am I missing something here? Note g uses a thread, f uses main context. I have this problem on win2K and win2K3. I'm currently using Python 2.4b1 and win32 package= pywin32-203.win32-py2.4.exe Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1601247&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-22 02:06:46
|
Bugs item #1598678, was opened at 2006-11-17 19:20 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ross Ridge (ross_ridge) Assigned to: Roger Upole (rupole) Summary: PyConsoleScreenBuffer doesn't keep reference to handle Initial Comment: PyConsoleScreenBufferType doesn't keep a reference to the PyHANDLE passed in when constructing an object. If you run the following test case: import win32con import win32file import win32console h = win32file.CreateFile("CONIN$", win32con.GENERIC_READ | win32con.GENERIC_WRITE, win32con.FILE_SHARE_READ | win32con.FILE_SHARE_WRITE, None, win32con.OPEN_EXISTING, 0, None) c = win32console.PyConsoleScreenBufferType(h) c.GetConsoleMode() # call 1 h = None c.GetConsoleMode() # call 2 You get the following output: Traceback (most recent call last): File "test2.py", line 12, in ? c.GetConsoleMode() # call 2 pywintypes.error: (6, 'GetConsoleMode', 'The handle is invalid.') The handle is invalid because it was closed after the previous line ("h = None") was executed despite the fact that "c" should still be maintaining a reference to the PyHANDLE object it's using. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-11-21 21:06 Message: Logged In: YES user_id=771074 Originator: NO It might be more consistent for the object to call DuplicateHandle internally. That way both types of handles could still be treated exactly the same. Plus, the caller would still be responsible for the original handle, so there would be no change from the existing semantics. Does this sound reasonable to you ? ---------------------------------------------------------------------- Comment By: Ross Ridge (ross_ridge) Date: 2006-11-19 14:51 Message: Logged In: YES user_id=1218032 Originator: YES I don't expect PyConsoleScreenBuffer to manage the lifetime of the handle, I expect PyHANDLE to do so. Since I'm passing a PyHANDLE object, not an actual Win32 HANDLE value, to PyConsoleScreenBuffer, I expect the PyConsoleScreenBuffer object to keep a reference to the PyHANDLE object so that the PyHANDLE object can do it's job. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-11-18 11:52 Message: Logged In: YES user_id=771074 Originator: NO The PyConsoleScreenBuffer object doesn't make any attempt to manage the lifetime of the handle when it's created from an existing handle. You can use h.Detach() to ensure that the handle isn't closed prematurely, or win32api.DuplicateHandle to make a copy of the handle. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-21 11:42:43
|
Bugs item #1483482, was opened at 2006-05-07 21:31 Message generated for change (Settings changed) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018 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: pythonwin Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) >Summary: losts assocs Initial Comment: build 208 PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32. Get occasionally a trace in the Pythonwin interactive pane - like this one recently when pressing Ctrl-F (find tool): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception I'm noticing this ["win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyC...' was requested."] occasionally in very random situations. Also in other standalone win32ui apps. This problem may relate to #1475467 (win32ui: Internal error-existing object is not of same type?). a "->GetGoodRet()" issue or similar problem? ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-21 12:40 Message: Logged In: YES user_id=972995 Originator: YES I'm reopening this bug. Just got this with build 210 (patch of GIL bug 1590399 already in): >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 430, in OnCmdEditFind find.ShowFindDialog() File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 36, in ShowFindDialog _ShowDialog(FindDialog) File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 50, in _ShowDialog curDialog = dlgClass() File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 162, in __init__ dialog.Dialog.__init__(self,self._GetDialogTemplate()) File "C:\Python23\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 32, in __init__ dlg=win32ui.CreateDialogIndirect(id) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCDialog' was requested. win32ui: Error in Command Message handler for command ID 57636, Code 0 Most probable its either still the unaddressed problem with CPythonWinThread::ExitInstance (destructor not cleaning up its assoc) problem as described below. Or its another lost object found randomly by ui_assoc_object::make (within win32ui.CreateDialogIndirect; as most of the ::make calls are not forcing to create objects anew but are likely to pick up on random sticky assocs to dead objects, which have not cleaned their assoc accidentally. (Thus big problems arises as consequence of "small" bug) -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-18 12:42 Message: Logged In: YES user_id=972995 Originator: YES bugs as far as concretely visible are solved now with patch of bug #1590399 The comment regarding the danger of typical ui_assoc_object::make usage "map lookups are very likely to pick up undeleted junk objects in the map" still could be interesting to avoid latent bugs in future. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-06-06 19:10 Message: Logged In: YES user_id=972995 Think, I found some of the sources for theses kind of bugs. I got many other such bugs reported. e.g.: File "app.pyo", line 2033, in WmSize\\n\', "win32ui: Internal error - existing object has type \'PyCWnd\', but \'PyCTabCtrl\' was requested.\\n"] I have these strong guesses for bugs: * CPythonWinThread::ExitInstance the MFC destroys the this pointer, but the assoc is not deleted! ==> junk items are pickup ==> bug in OP (see skipLookup problem below) * ui_propsheet_get_tab_ctrl: permanent ui_assoc_object::make is called on temporary pTab = pPS->GetTabControl() !! (MFC uses FromHandle !) PyCWnd::make should be used or something similar to make it permanent as required for a Python-Object * (for example!): PyCWinThread::create, PyCFormView::create, PyCEditView::create, ... (and in most ::create functions) ui_assoc_object::make( PyCWinThread::type, pThread ) is called with default skipLookup=FALSE even if the C object was created brandnew (with 'new' - which is in done in 95% of cases) ! ==> Those map lookups are very likely to pick up undeleted junk objects in the map ! ==> when Objects are created new, skipLookup=TRUE should be used - or FALSE the default and TRUE only for GetXXX things - or best a new ui_assoc_object::makenew should be used. Think this is very important and I attribute many other strange win32ui - Internal errors to this risky map management. * ui_assoc_object::GetGoodRet DODECREF better to be done after DOINCREF !? -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-07 21:32 Message: Logged In: YES user_id=972995 trace again (as initial posting removes whitespace): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-21 11:40:51
|
Bugs item #1483482, was opened at 2006-05-07 21:31 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018 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: pythonwin Group: None >Status: Open Resolution: None Priority: 8 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Occasionally strange object mixup with GetDlgItem() Initial Comment: build 208 PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32. Get occasionally a trace in the Pythonwin interactive pane - like this one recently when pressing Ctrl-F (find tool): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception I'm noticing this ["win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyC...' was requested."] occasionally in very random situations. Also in other standalone win32ui apps. This problem may relate to #1475467 (win32ui: Internal error-existing object is not of same type?). a "->GetGoodRet()" issue or similar problem? ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-11-21 12:40 Message: Logged In: YES user_id=972995 Originator: YES I'm reopening this bug. Just got this with build 210 (patch of GIL bug 1590399 already in): >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 430, in OnCmdEditFind find.ShowFindDialog() File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 36, in ShowFindDialog _ShowDialog(FindDialog) File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 50, in _ShowDialog curDialog = dlgClass() File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 162, in __init__ dialog.Dialog.__init__(self,self._GetDialogTemplate()) File "C:\Python23\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 32, in __init__ dlg=win32ui.CreateDialogIndirect(id) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCDialog' was requested. win32ui: Error in Command Message handler for command ID 57636, Code 0 Most probable its either still the unaddressed problem with CPythonWinThread::ExitInstance (destructor not cleaning up its assoc) problem as described below. Or its another lost object found randomly by ui_assoc_object::make (within win32ui.CreateDialogIndirect; as most of the ::make calls are not forcing to create objects anew but are likely to pick up on random sticky assocs to dead objects, which have not cleaned their assoc accidentally. (Thus big problems arises as consequence of "small" bug) -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-18 12:42 Message: Logged In: YES user_id=972995 Originator: YES bugs as far as concretely visible are solved now with patch of bug #1590399 The comment regarding the danger of typical ui_assoc_object::make usage "map lookups are very likely to pick up undeleted junk objects in the map" still could be interesting to avoid latent bugs in future. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-06-06 19:10 Message: Logged In: YES user_id=972995 Think, I found some of the sources for theses kind of bugs. I got many other such bugs reported. e.g.: File "app.pyo", line 2033, in WmSize\\n\', "win32ui: Internal error - existing object has type \'PyCWnd\', but \'PyCTabCtrl\' was requested.\\n"] I have these strong guesses for bugs: * CPythonWinThread::ExitInstance the MFC destroys the this pointer, but the assoc is not deleted! ==> junk items are pickup ==> bug in OP (see skipLookup problem below) * ui_propsheet_get_tab_ctrl: permanent ui_assoc_object::make is called on temporary pTab = pPS->GetTabControl() !! (MFC uses FromHandle !) PyCWnd::make should be used or something similar to make it permanent as required for a Python-Object * (for example!): PyCWinThread::create, PyCFormView::create, PyCEditView::create, ... (and in most ::create functions) ui_assoc_object::make( PyCWinThread::type, pThread ) is called with default skipLookup=FALSE even if the C object was created brandnew (with 'new' - which is in done in 95% of cases) ! ==> Those map lookups are very likely to pick up undeleted junk objects in the map ! ==> when Objects are created new, skipLookup=TRUE should be used - or FALSE the default and TRUE only for GetXXX things - or best a new ui_assoc_object::makenew should be used. Think this is very important and I attribute many other strange win32ui - Internal errors to this risky map management. * ui_assoc_object::GetGoodRet DODECREF better to be done after DOINCREF !? -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-07 21:32 Message: Logged In: YES user_id=972995 trace again (as initial posting removes whitespace): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 14:11:17
|
Bugs item #1597081, was opened at 2006-11-15 17:08 Message generated for change (Comment added) made by ckuhlmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1597081&group_id=78018 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: pythonwin Group: None >Status: Closed Resolution: None Priority: 2 Private: No Submitted By: CKuhlmann (ckuhlmann) Assigned to: Nobody/Anonymous (nobody) Summary: forgotten menu entry Initial Comment: In PythonWin build 210, there's still the menu entry "Other" in menu "Help". This seems to have been forgotten to be removed as the PythonCOM and win32extensions help are now included in PyWin32.chm. ---------------------------------------------------------------------- >Comment By: CKuhlmann (ckuhlmann) Date: 2006-11-20 15:11 Message: Logged In: YES user_id=1646195 Originator: YES Ok, I understand. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-11-20 12:56 Message: Logged In: YES user_id=14198 Originator: NO Actually, the intent (and code) allows for any extension to register a help file via their installer, and it will appear. While I'm not aware of anyone leveraging this, I'm reluctant to remove the functionality for now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1597081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 12:43:11
|
Bugs item #1571838, was opened at 2006-10-06 11:14 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1571838&group_id=78018 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: win32 Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Error Message Missing Initial Comment: I'm running Win98 with Python 2.4.3, and I'm writing a module to generalize printing under Windows. I felt sure that one call wouldn't work on Win98, and sure enough it didn't: U:\Source\MSWinPrint>python mswinprint.py Traceback (most recent call last): File "mswinprint.py", line 252, in ? doc.begin_document() File "mswinprint.py", line 116, in begin_document devmode = win32print.GetPrinter(self.hprinter, 8)["pDevMode"] TypeError: GetPrinter() takes exactly 1 argument (2 given) But I realized I was running build 203, so I upgraded to build 209, and tried again: U:\Source\MSWinPrint>python mswinprint.py Traceback (most recent call last): File "mswinprint.py", line 252, in ? doc.begin_document() File "mswinprint.py", line 116, in begin_document devmode = win32print.GetPrinter(self.hprinter, 8)["pDevMode"] pywintypes.error: (0, 'GetPrinter', 'No error message is available') Now, I'm pretty sure the first version behavior is better than the second. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-11-20 23:43 Message: Logged In: YES user_id=14198 Originator: NO Not much we can/should do about this ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-10-06 13:09 Message: Logged In: YES user_id=771074 In build 203, win32print.GetPrinter didn't accept an information level parm, alway using lvl 2. According to MSDN, on Win98 only 1,2 and 5 are valid levels for GetPrinter. Apparently the API function isn't setting an error code when passed a level that isn't supported on 98. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1571838&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 12:41:00
|
Bugs item #1599609, was opened at 2006-11-20 10:57 Message generated for change (Comment added) made by ainrialai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1599609&group_id=78018 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: installation Group: None Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: blast (ainrialai) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot install on windows - expects python 2.2 Initial Comment: Hello there, First of all, I am not sure that this is bug, but it is a problem and I have not been able to find any where to get an answer. I downloaded and instaled python 2.5 for windows. It seems to work ok. My system is windows 2000 professional. I am looking for a simple tool to create windows GUI i/f for a db .. hence the interest in this extension. I downloaded the pywin binary for wondows and when I try to install it stops on the second window of the wizard with "Python version 2.2 required, not found in windows registry". True - I have installed version 2.5. Is this extension not compatible with 2.5? do I need to install version 2.2? Should this not be listed as "Installion check list" for review prior to downloading? Thank you for your hard work! paul ---------------------------------------------------------------------- >Comment By: blast (ainrialai) Date: 2006-11-20 12:41 Message: Logged In: YES user_id=1649673 Originator: YES Yes - I figured it was something pretty trivial thanka p ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-11-20 11:50 Message: Logged In: YES user_id=14198 Originator: NO You have downloaded the 2.2 specific version - check the download page carefully and you will find the 2.5 version. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1599609&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 12:38:56
|
Bugs item #1556914, was opened at 2006-09-12 18:16 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1556914&group_id=78018 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: installation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: yabbadabba23 (yabbadabba23) Assigned to: Nobody/Anonymous (nobody) Summary: warnex() not found in python25.dll Initial Comment: Plattform: WinXP SP2 Installer used: pywin32-209.1.win32-py2.5.exe Python version: 2.5b2 r50512 Error message: Entry point "PyErr_WarnEx" in "python25.dll" not found Also see: http://mail.python.org/pipermail/python-checkins/2006-August/055244.html ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-11-20 23:38 Message: Logged In: YES user_id=14198 Originator: NO 209.1 and later builds address this ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-13 18:35 Message: Logged In: YES user_id=771074 Build 209.1 should work with Python 2.5c1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1556914&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 12:37:49
|
Bugs item #1590399, was opened at 2006-11-04 21:12 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1590399&group_id=78018 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: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Refcounting / GIL problems (dual) Initial Comment: I wonder if the below patch possibly addresses a refcount/memory problem. Think its possible, that DODECREF(this) frees <*this> from memory, another released threads malloc uses the memory and this->virtualInst is bogus? ( In preceding function ui_assoc_object::DoKillAssoc there is a simlar technique to do "PyObject *vi = virtualInst;" - but for reverse reason ) ( I'm still in search of memory leaks/crashes on dual cores and fast CPUs when other threads are going on parallel to win32ui GUI mainthread. ) --- win32assoc.cpp.orig 2005-04-12 17:01:00.000000000 +0200 +++ win32assoc.cpp 2006-11-04 10:59:46.326646400 +0100 @@ -252,9 +252,10 @@ { if (this==NULL) return NULL; if (virtualInst) { + PyObject *vi = virtualInst; + DOINCREF(vi); DODECREF(this); - DOINCREF(virtualInst); - return virtualInst; + return vi; } else return this; } ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-11-20 23:37 Message: Logged In: YES user_id=14198 Originator: NO (Very slightly modified version) checked in - thanks! Checking in win32assoc.cpp; new revision: 1.8; previous revision: 1.7 Checking in win32virt.cpp; new revision: 1.4; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-08 20:12 Message: Logged In: YES user_id=972995 Meanwhile there is significant feedback that c_GIL_bugs.patch in fact solved all the crash problems with threaded apps on all (dual core) machines. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-06 07:00 Message: Logged In: YES user_id=972995 In attachment a patch candidate I've so far in action for all these things. (That issue around "pExistingAppObject" was nonsense. pExistingAppObject seems to be not set to anything at all) Notes: The speed DECREF's in ~CVirtualHelper are switched all off by this patch - as it seems to not be valid so outside of the GIL. Would require a __asm LOCK INC/DEC or so. Have not seen serious speed issues in apps so far. Yet I've seen: most often CVirtualHelp is instanciated - costing a enter/leave python state switch - and then immediately a helper.call(..) with again a enter/leave state switch. If optimization necessary, possibly by a CVirtualHelpE does it which enters Python in constructor until destruction and the .call's do not again have to enter. Only few locations, where the intermediate PythonLeave/GUI_BGN_SAVE is necessary. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-05 02:49 Message: Logged In: YES user_id=972995 Think I found other serious potential refcount/GIL problems which cause crashes here in apps with threads - mainly on dual core - and set priority to 9: I looked over GUI_BGN_SAVE's => Py_XINC/DECREF's outside of the GIL. this causes probably the special problems only on dual cores when multiple threads: win32cmdui/Line120: GUI_BGN_SAVE; Python_delete_assoc(ob); GUI_END_SAVE; win32uimodule/Line650: void Python_delete_assoc( void *ob ) { // Notify Python object of my attached object removal. { CVirtualHelper helper ("OnAttachedObjectDeath", ob); <================ helper.call(); <================ } ui_assoc_object *pObj; if ((pObj=ui_assoc_object::GetPyObject(ob)) && !bInFatalShutdown) { CEnterLeavePython _celp; // KillAssoc requires it is held! pObj->KillAssoc(); } } win32virt.cpp/Line22 CVirtualHelper::CVirtualHelper(const char *iname, const void *iassoc, EnumVirtualErrorHandling veh/* = VEH_PRINT_ERROR */) { handler=NULL; py_ob = NULL; ... py_ob = py_bob; Py_INCREF(py_ob); <================ // Py_XINCREF(handler); } The gross hack for speed in CVirtualHelper::~CVirtualHelper() will not work for dual cores. A fast "ZDODECREF/ZDODECREF" independent of GIL (unless it went to 0) would be possible on x86 with "__asm LOCK DEC <(op)->ob_refcnt>" or so. see: http://groups.google.de/group/comp.lang.python/msg/ef530d4448814391 CVirtualHelper::~CVirtualHelper() { // XXX - Gross hack for speed. This is called for eachh window message // so only grabs the Python lock if the objects need Python, if ((retVal && retVal->ob_refcnt==1) || <================ DECREF not atomic on multi-core CPU's (handler && handler->ob_refcnt==1) || (py_ob && py_ob->ob_refcnt==1)) { CEnterLeavePython _celp; XDODECREF(retVal); XDODECREF(handler); XDODECREF(py_ob); } else { XDODECREF(retVal); <================ DECREF not atomic on multi-core CPU's XDODECREF(handler); XDODECREF(py_ob); } } Maybe there are other loose INCREFS / DECREFS in win32 code? And I found - probably most serious in this list - : Only CVirtualHelper::do_call is CEnterLeavePython protected: BOOL CVirtualHelper::do_call(PyObject *args) { CEnterLeavePython _celp; XDODECREF(retVal); // our old one. retVal = NULL; but all entrace call functions are not - but they are bulding up Python Values ! Think that is serious (even on single cores where I have very rare crashes): e.g.: BOOL CVirtualHelper::call() { if (!handler) return FALSE; PyObject *arglst = Py_BuildValue("()"); <================ return do_call(arglst); } =>Probably the CEnterleave protection should be moved out of do_call to all entrance call(...)'s & call_args() ? Looked in a rush over the 200 base DECREFs in Pythonwin. Found so far no other smelling refcounting. Only maybe this is invalid : --- win32app.cpp.orig 2006-01-10 15:38:00.000000000 +0100 +++ win32app.cpp 2006-11-04 16:44:24.009694400 +0100 @@ -412,6 +412,7 @@ { PyCWinThread::cleanup(); // total hack! - while (pExistingAppObject) + while (pExistingAppObject->ob_refcnt>1) DODECREF(pExistingAppObject); // this may delete it. + DODECREF(pExistingAppObject); } ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-04 21:22 Message: Logged In: YES user_id=972995 (repeated) --- win32assoc.cpp.orig 2005-04-12 17:01:00.000000000 +0200 +++ win32assoc.cpp 2006-11-04 10:59:46.326646400 +0100 @@ -252,9 +252,10 @@ { if (this==NULL) return NULL; if (virtualInst) { + PyObject *vi = virtualInst; + DOINCREF(vi); DODECREF(this); - DOINCREF(virtualInst); - return virtualInst; + return vi; } else return this; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1590399&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 11:56:23
|
Bugs item #1597081, was opened at 2006-11-16 03:08 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1597081&group_id=78018 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: pythonwin Group: None Status: Open Resolution: None >Priority: 2 Private: No Submitted By: CKuhlmann (ckuhlmann) Assigned to: Nobody/Anonymous (nobody) Summary: forgotten menu entry Initial Comment: In PythonWin build 210, there's still the menu entry "Other" in menu "Help". This seems to have been forgotten to be removed as the PythonCOM and win32extensions help are now included in PyWin32.chm. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-11-20 22:56 Message: Logged In: YES user_id=14198 Originator: NO Actually, the intent (and code) allows for any extension to register a help file via their installer, and it will appear. While I'm not aware of anyone leveraging this, I'm reluctant to remove the functionality for now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1597081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 11:50:27
|
Bugs item #1599609, was opened at 2006-11-20 21:57 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1599609&group_id=78018 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: installation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: blast (ainrialai) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot install on windows - expects python 2.2 Initial Comment: Hello there, First of all, I am not sure that this is bug, but it is a problem and I have not been able to find any where to get an answer. I downloaded and instaled python 2.5 for windows. It seems to work ok. My system is windows 2000 professional. I am looking for a simple tool to create windows GUI i/f for a db .. hence the interest in this extension. I downloaded the pywin binary for wondows and when I try to install it stops on the second window of the wizard with "Python version 2.2 required, not found in windows registry". True - I have installed version 2.5. Is this extension not compatible with 2.5? do I need to install version 2.2? Should this not be listed as "Installion check list" for review prior to downloading? Thank you for your hard work! paul ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-11-20 22:50 Message: Logged In: YES user_id=14198 Originator: NO You have downloaded the 2.2 specific version - check the download page carefully and you will find the 2.5 version. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1599609&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-20 10:57:21
|
Bugs item #1599609, was opened at 2006-11-20 10:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1599609&group_id=78018 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: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: blast (ainrialai) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot install on windows - expects python 2.2 Initial Comment: Hello there, First of all, I am not sure that this is bug, but it is a problem and I have not been able to find any where to get an answer. I downloaded and instaled python 2.5 for windows. It seems to work ok. My system is windows 2000 professional. I am looking for a simple tool to create windows GUI i/f for a db .. hence the interest in this extension. I downloaded the pywin binary for wondows and when I try to install it stops on the second window of the wizard with "Python version 2.2 required, not found in windows registry". True - I have installed version 2.5. Is this extension not compatible with 2.5? do I need to install version 2.2? Should this not be listed as "Installion check list" for review prior to downloading? Thank you for your hard work! paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1599609&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-19 19:51:23
|
Bugs item #1598678, was opened at 2006-11-17 19:20 Message generated for change (Comment added) made by ross_ridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ross Ridge (ross_ridge) Assigned to: Roger Upole (rupole) Summary: PyConsoleScreenBuffer doesn't keep reference to handle Initial Comment: PyConsoleScreenBufferType doesn't keep a reference to the PyHANDLE passed in when constructing an object. If you run the following test case: import win32con import win32file import win32console h = win32file.CreateFile("CONIN$", win32con.GENERIC_READ | win32con.GENERIC_WRITE, win32con.FILE_SHARE_READ | win32con.FILE_SHARE_WRITE, None, win32con.OPEN_EXISTING, 0, None) c = win32console.PyConsoleScreenBufferType(h) c.GetConsoleMode() # call 1 h = None c.GetConsoleMode() # call 2 You get the following output: Traceback (most recent call last): File "test2.py", line 12, in ? c.GetConsoleMode() # call 2 pywintypes.error: (6, 'GetConsoleMode', 'The handle is invalid.') The handle is invalid because it was closed after the previous line ("h = None") was executed despite the fact that "c" should still be maintaining a reference to the PyHANDLE object it's using. ---------------------------------------------------------------------- >Comment By: Ross Ridge (ross_ridge) Date: 2006-11-19 14:51 Message: Logged In: YES user_id=1218032 Originator: YES I don't expect PyConsoleScreenBuffer to manage the lifetime of the handle, I expect PyHANDLE to do so. Since I'm passing a PyHANDLE object, not an actual Win32 HANDLE value, to PyConsoleScreenBuffer, I expect the PyConsoleScreenBuffer object to keep a reference to the PyHANDLE object so that the PyHANDLE object can do it's job. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-11-18 11:52 Message: Logged In: YES user_id=771074 Originator: NO The PyConsoleScreenBuffer object doesn't make any attempt to manage the lifetime of the handle when it's created from an existing handle. You can use h.Detach() to ensure that the handle isn't closed prematurely, or win32api.DuplicateHandle to make a copy of the handle. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-18 16:56:11
|
Feature Requests item #1567449, was opened at 2006-09-28 22:29 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1567449&group_id=78018 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: com Group: Next Release (example) >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) Assigned to: Nobody/Anonymous (nobody) Summary: Dynamic Cast of COM Pointers Initial Comment: I don't know how many other COM libraries do this, but specifically with iTunes, the Interfaces defined for tracks form a hierarchy (in python-speak): class Track(Item): pass class FileOrCDTrack(Track): pass class URLTrack(Track): pass The problem is, a number of interfaces are defined to return a pointer to a Track interface when in fact one can test the object and safely refer to it via a derived interface. For instance, iTunesApp.CurrentTrack returns a Track interface pointer, even if it is a FileOrCDTrack. In fact, all but 1 interface prevents the user from accessing the derived class properties (which include a lot of new features that are part of the base class in AppleScript). Direct Indexing by name, ID or playlist order all return a pointer to the base interface. Thus, none of these allow access to the derived attributes in FileOrCDTrack even if the track is indeed a File or CD based track. So the ONLY way to retrieve the derived interface is to use the Enum method of the LibraryPlaylist object and iterate through ALL the tracks known, which in a large library can take an astronomical amount of time. The Enum method does however properly return FileOrCDTrack interfaces when appropriate. The idea of the Dynamic Cast would therefore be to allow the user to perform a C++ style dynamic_cast on an interface to convert it to a different interface. In this example, one would take a track instance, call it's 'kind' property to verify that it was a FileOrCDTrack and then cast the interface pointer from a Track interface to a FileOrCDTrack. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-11-18 11:56 Message: Logged In: YES user_id=771074 Originator: NO Since there are already two different ways to accomplish this, closing as out of date. Roger ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2006-10-04 09:12 Message: Logged In: YES user_id=977439 Try from win32com.client import CastTo FileTrack = CastTo(iTunesApp.CurrentTrack, "FileOrCDTrack") this should help. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-28 23:16 Message: Logged In: YES user_id=771074 You should be able to do this using QueryInterface. The attached code takes an IITTrack object and gets an IITFileOrCDTrack interface from it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1567449&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-18 16:52:21
|
Bugs item #1598678, was opened at 2006-11-17 19:20 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ross Ridge (ross_ridge) >Assigned to: Roger Upole (rupole) Summary: PyConsoleScreenBuffer doesn't keep reference to handle Initial Comment: PyConsoleScreenBufferType doesn't keep a reference to the PyHANDLE passed in when constructing an object. If you run the following test case: import win32con import win32file import win32console h = win32file.CreateFile("CONIN$", win32con.GENERIC_READ | win32con.GENERIC_WRITE, win32con.FILE_SHARE_READ | win32con.FILE_SHARE_WRITE, None, win32con.OPEN_EXISTING, 0, None) c = win32console.PyConsoleScreenBufferType(h) c.GetConsoleMode() # call 1 h = None c.GetConsoleMode() # call 2 You get the following output: Traceback (most recent call last): File "test2.py", line 12, in ? c.GetConsoleMode() # call 2 pywintypes.error: (6, 'GetConsoleMode', 'The handle is invalid.') The handle is invalid because it was closed after the previous line ("h = None") was executed despite the fact that "c" should still be maintaining a reference to the PyHANDLE object it's using. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-11-18 11:52 Message: Logged In: YES user_id=771074 Originator: NO The PyConsoleScreenBuffer object doesn't make any attempt to manage the lifetime of the handle when it's created from an existing handle. You can use h.Detach() to ensure that the handle isn't closed prematurely, or win32api.DuplicateHandle to make a copy of the handle. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-18 11:55:24
|
Bugs item #1361822, was opened at 2005-11-20 01:36 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: crash when or after importing scipy - Build 205 Initial Comment: This has happened a number of times but I haven't been able to pin it down to more than the fact it occurs when attempting to debug a program using scipy. If the code is executed first, then one can step through it. In this case a crash often occurs eventually. The crash report is the instruction "0x7c168f1d" could not read "0x0000001c" Colin W. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-18 12:55 Message: Logged In: YES user_id=972995 Originator: NO sounds more like a memory leak problem of scipy itself. But see a small probabilty that patch/solution for #1590399 solves it (in binary build >=211). ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2006-01-12 02:09 Message: Logged In: YES user_id=285587 Mark, Attached is the script ugh1.py If I Run, the results are as expected. If I Step into, stepover (the print command) Step into the import command and continue stepping into, we crash on the umath reference. I've had similar problems with Boa-Contructor and PyScripter. I hope that this helps. Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 06:07 Message: Logged In: YES user_id=14198 Can you please provide instructions on how I can reproduce it? Cheers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-18 11:50:03
|
Bugs item #1448160, was opened at 2006-03-12 07:09 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1448160&group_id=78018 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: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Darren (zaphod72) Assigned to: Nobody/Anonymous (nobody) Summary: Win2003 dual-core crash on startup Initial Comment: I have a dual-core Windows Server 2003 and a single- core server also running Windows Server 2003. On the dual-core pythonwin crashes on startup, shortly after displaying the UI. On the single-core it works fine. Here's the crash info from WinDbg - (ee8.8b8): Access violation - code c0000005 (!!! second chance !!!) eax=00000000 ebx=773e20e0 ecx=000080a2 edx=001668d8 esi=0013fcf8 edi=7ffdf6cc eip=00a0180c esp=0013fcd4 ebp=0013fd04 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 00a0180c 58 pop eax And the stack trace - ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 0013fcd0 77387050 000080a2 00000000 00000000 0xa0180c 0013fd04 77387dc3 00a0180c 000080a2 00000000 USER32! UserCallDDECallback+0x23 0013fd3c 77387101 0015ca78 000080a2 00000000 USER32! DoCallback+0x6a 0013fd74 7738e3f0 0015ca78 000004c8 0000c02c USER32! ProcessRegistrationMessage+0xa4 0013fd8c 7739c3b7 001500ce 000004c8 0000c02c USER32! DDEMLMotherWndProc+0x2c 0013fdb8 7739c484 7738e3ad 001500ce 000004c8 USER32! InternalCallWinProc+0x28 0013fe30 7739c73c 00000000 7738e3ad 001500ce USER32! UserCallWinProcCheckWow+0x151 0013fe98 7738e406 00155998 00000001 00000000 USER32! DispatchMessageWorker+0x327 0013fea8 7c169076 00155998 00155998 00403040 USER32! DispatchMessageA+0xf 0013feb8 7c16913e 00403040 1e055870 0013ffc0 MFC71! AfxInternalPumpMessage+0x3e 0013fed4 1e2b6767 00403040 ffffffff 00000000 MFC71! CWinThread::Run+0x54 0013ffc0 77e523cd 00000000 00000000 7ffdc000 win32ui! Python_callback+0x1247 0013fff0 00000000 0040186c 00000000 78746341 kernel32! BaseProcessStart+0x23 I didn't try to build the source. But if I can get the pdb files then I'd be happy to try and get some more information (darrenk at yahoo). Thanks ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-18 12:49 Message: Logged In: YES user_id=972995 Originator: NO Think the probability is very high that this will be solved with patch of bug #1590399 also. there were GIL-Problems and INC/DEC's of refcounts outside of the GIL which are non-atomic on dual cores. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-09-22 14:49 Message: Logged In: YES user_id=14198 I'm guessing this will work with -nodde specified on the command-line. I'd love to remove that - sadly the DDE code is fairly intractable :( I wouldn't know where to ask you to start with the .pdb files ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-14 17:57 Message: Logged In: YES user_id=972995 Good to get more about this dual core bug (following #1442426 & #1441884 ) Can you maybe try this bug also with py2.3.5 / build 205 ? (build 207 doesn't work for py2.3). You can simply run a second py2.3 installation parallel on your computer. Such test would exclude the py2.4/MFC7.1 scheme as reason for the crash. I sent you that win32ui with .pdb: That should provide detailed stack traces. --- related: #1442426 , #1441884 http://sourceforge.net/tracker/index.php?func=detail&aid=1441884&group_id=5470&atid=105470 --- I got similar user reports for a win32ui-app (build 203/MFC4.2/py2.3.5; even without pythonwin IDE). Unfortunately I got no stack traces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1448160&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-18 11:43:56
|
Bugs item #1475467, was opened at 2006-04-24 13:47 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1475467&group_id=78018 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: pythonwin Group: None >Status: Closed Resolution: None Priority: 6 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: win32ui: Internal error-existing object is not of same type? Initial Comment: I get rare reports with this error: "win32ui: Internal error - existing object is not of same type as requested new object" (the last was on a Win XP Prof; build 208 or build205 - not sure) it traces to a bare: tt=win32ui.CreateToolTipCtrl();tt.CreateWindow(parent,0) I don't even find the above error string in the pywin32 sources. Only "Internal error - existing object has type..." in win32assoc.cpp What error is this "existing object is not of same type as requested new object"? Most probably it has to do with (win32tooltip.cpp): return ui_assoc_object::make( PyCToolTipCtrl::type, pTTC ); Many of such ::make's in the win32ui sources have a "->GetGoodRet()" on the line. Some have not. What is the criteria? Is such ->GetGoodRet() maybe necessary in that win32tooltip.cpp location? Can a misbehaviour on such ::make's also cause crashes? (I have occasional mem. access crash reports also; mainly on dual core's) -robert ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-11-18 12:43 Message: Logged In: YES user_id=972995 Originator: YES bugs as far as concretely visible are solved now with patch of bug #1590399 The comment regarding the danger of typical ui_assoc_object::make usage "ui_assoc_object::make should by default NOT look up, but force-create/replace the assoc" still could be interesting in order to avoid latent bugs in future. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-06-07 13:52 Message: Logged In: YES user_id=972995 as explained in #1483482 this would also most probably be forced correct with ui_assoc_object::make(..., skipLookup=TRUE). The source of the error can be ANY stale temp/wrong/lost assoc in the map: any possible flaw in 1000's of assoc creations in the win32ui code - probably from PyCWinThread's (not cleaned up with ExitInstance). Yet the real problem are not some few (lost/bug) assoc's, but the fact that ANY lost assoc can make everthing instable and case OS-crashes. Meanwhile I'd say not even ui_assoc_object::makenew is the best solution for this (requires 1000's code locations to be changed), but maybe ui_assoc_object::make should by default NOT look up, but force-create/replace the assoc. There are only quite few locations in win32ui where maybe a ui_assoc_object::lookupmake has to be done (and if some are forgotten its not serious - only a new python object will be created at some cost - a DEBUG warning could tell that with time) So the change would be comparably simple: * set skipLookup=TRUE by default * put a mere DEBUG warning if a replaced assoc changes the type (==> indicates illegal use of temporary/lost C-assocs) * search those very very few locations in win32ui code where ui_assoc_object::make is used upon GetXXXX-functions which are really by guarantee not createing new C-objects, but (re-)provide permanent C-Objects. ( in most GetXXX-functions already PyCWnd::make is used correctly and not ui_assoc_object::make !) Think that would greatly improve the stability of win32ui regarding internal errors and random crashes. -robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1475467&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-18 11:42:25
|
Bugs item #1483482, was opened at 2006-05-07 21:31 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018 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: pythonwin Group: None >Status: Closed Resolution: None Priority: 8 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Occasionally strange object mixup with GetDlgItem() Initial Comment: build 208 PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32. Get occasionally a trace in the Pythonwin interactive pane - like this one recently when pressing Ctrl-F (find tool): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception I'm noticing this ["win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyC...' was requested."] occasionally in very random situations. Also in other standalone win32ui apps. This problem may relate to #1475467 (win32ui: Internal error-existing object is not of same type?). a "->GetGoodRet()" issue or similar problem? ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-11-18 12:42 Message: Logged In: YES user_id=972995 Originator: YES bugs as far as concretely visible are solved now with patch of bug #1590399 The comment regarding the danger of typical ui_assoc_object::make usage "map lookups are very likely to pick up undeleted junk objects in the map" still could be interesting to avoid latent bugs in future. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-06-06 19:10 Message: Logged In: YES user_id=972995 Think, I found some of the sources for theses kind of bugs. I got many other such bugs reported. e.g.: File "app.pyo", line 2033, in WmSize\\n\', "win32ui: Internal error - existing object has type \'PyCWnd\', but \'PyCTabCtrl\' was requested.\\n"] I have these strong guesses for bugs: * CPythonWinThread::ExitInstance the MFC destroys the this pointer, but the assoc is not deleted! ==> junk items are pickup ==> bug in OP (see skipLookup problem below) * ui_propsheet_get_tab_ctrl: permanent ui_assoc_object::make is called on temporary pTab = pPS->GetTabControl() !! (MFC uses FromHandle !) PyCWnd::make should be used or something similar to make it permanent as required for a Python-Object * (for example!): PyCWinThread::create, PyCFormView::create, PyCEditView::create, ... (and in most ::create functions) ui_assoc_object::make( PyCWinThread::type, pThread ) is called with default skipLookup=FALSE even if the C object was created brandnew (with 'new' - which is in done in 95% of cases) ! ==> Those map lookups are very likely to pick up undeleted junk objects in the map ! ==> when Objects are created new, skipLookup=TRUE should be used - or FALSE the default and TRUE only for GetXXX things - or best a new ui_assoc_object::makenew should be used. Think this is very important and I attribute many other strange win32ui - Internal errors to this risky map management. * ui_assoc_object::GetGoodRet DODECREF better to be done after DOINCREF !? -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-07 21:32 Message: Logged In: YES user_id=972995 trace again (as initial posting removes whitespace): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-18 00:20:41
|
Bugs item #1598678, was opened at 2006-11-17 19:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ross Ridge (ross_ridge) Assigned to: Nobody/Anonymous (nobody) Summary: PyConsoleScreenBuffer doesn't keep reference to handle Initial Comment: PyConsoleScreenBufferType doesn't keep a reference to the PyHANDLE passed in when constructing an object. If you run the following test case: import win32con import win32file import win32console h = win32file.CreateFile("CONIN$", win32con.GENERIC_READ | win32con.GENERIC_WRITE, win32con.FILE_SHARE_READ | win32con.FILE_SHARE_WRITE, None, win32con.OPEN_EXISTING, 0, None) c = win32console.PyConsoleScreenBufferType(h) c.GetConsoleMode() # call 1 h = None c.GetConsoleMode() # call 2 You get the following output: Traceback (most recent call last): File "test2.py", line 12, in ? c.GetConsoleMode() # call 2 pywintypes.error: (6, 'GetConsoleMode', 'The handle is invalid.') The handle is invalid because it was closed after the previous line ("h = None") was executed despite the fact that "c" should still be maintaining a reference to the PyHANDLE object it's using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-17 19:04:58
|
Feature Requests item #1598560, was opened at 2006-11-17 20:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1598560&group_id=78018 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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erol Aktay (moghe) Assigned to: Nobody/Anonymous (nobody) Summary: SetWindowsHookEx Initial Comment: Hi, would be nice if you could make global hooks in pywin32 without relying on extra libraries like pyHook. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1598560&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-15 21:36:50
|
Bugs item #1596989, was opened at 2006-11-16 00:35 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1596989&group_id=78018 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: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Denis Komarov (denis_komarov) Assigned to: Nobody/Anonymous (nobody) Summary: problem with Session.ModelObjects() ERwin COM API Initial Comment: I'm hoping this is a coding error on my part, but I've encountered a problem with interface that I cannot understand. I try to use pywin32 (build 210 for Python 2.4) on WinXP for access to AllFusion ERwin Data Modeler 7.1 (Computer Associates) via ERwin COM API: ------------------------- begin erwin.py import win32com.client ERwin = win32com.client.dynamic.Dispatch('AllFusionERwin.SCAPI') PersistenceUnit = ERwin.PersistenceUnits.Add(r'D:\s\model.erwin') Session = ERwin.Sessions.Add() ModelSet = PersistenceUnit.ModelSet() Session.Open(ModelSet) ModelObjects = Session.ModelObjects() ------------------------- end erwin.py Traceback (most recent call last): File "D:\Project\erwin\src\root\nested\erwin.py", line 7, in ? ModelObjects = Session.ModelObjects() File "C:\Python24\Lib\site-packages\win32com\client\dynamic.py", line 172, in __call__ return self._get_good_object_(self._oleobj_.Invoke(*allArgs),self._olerepr_.defaultDispatchName,None) pywintypes.com_error: (-2147352562, '\xcd\xe5\xe4\xee\xef\xf3\xf1\xf2\xe8\xec\xee\xe5 \xf7\xe8\xf1\xeb\xee \xef\xe0\xf0\xe0\xec\xe5\xf2\xf0\xee\xe2.', None, None) Any insight into this problem would be most appreciated. Regards, Denis V. Komarov ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-11-16 08:36 Message: Logged In: YES user_id=14198 Originator: NO I've no idea why the bizarre string was displayed, but the error message for -2147352562 should be: >>> pythoncom.GetScodeString(-2147352562) 'Invalid number of parameters.' Which may give you a clue. Otherwise, I suggest you try asking on the pyt...@py... mailing list where more people will see it. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1596989&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-15 16:08:00
|
Bugs item #1597081, was opened at 2006-11-15 17:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1597081&group_id=78018 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: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: CKuhlmann (ckuhlmann) Assigned to: Nobody/Anonymous (nobody) Summary: forgotten menu entry Initial Comment: In PythonWin build 210, there's still the menu entry "Other" in menu "Help". This seems to have been forgotten to be removed as the PythonCOM and win32extensions help are now included in PyWin32.chm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1597081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-15 13:35:30
|
Bugs item #1596989, was opened at 2006-11-15 16:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1596989&group_id=78018 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: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Denis Komarov (denis_komarov) Assigned to: Nobody/Anonymous (nobody) Summary: problem with Session.ModelObjects() ERwin COM API Initial Comment: I'm hoping this is a coding error on my part, but I've encountered a problem with interface that I cannot understand. I try to use pywin32 (build 210 for Python 2.4) on WinXP for access to AllFusion ERwin Data Modeler 7.1 (Computer Associates) via ERwin COM API: ------------------------- begin erwin.py import win32com.client ERwin = win32com.client.dynamic.Dispatch('AllFusionERwin.SCAPI') PersistenceUnit = ERwin.PersistenceUnits.Add(r'D:\s\model.erwin') Session = ERwin.Sessions.Add() ModelSet = PersistenceUnit.ModelSet() Session.Open(ModelSet) ModelObjects = Session.ModelObjects() ------------------------- end erwin.py Traceback (most recent call last): File "D:\Project\erwin\src\root\nested\erwin.py", line 7, in ? ModelObjects = Session.ModelObjects() File "C:\Python24\Lib\site-packages\win32com\client\dynamic.py", line 172, in __call__ return self._get_good_object_(self._oleobj_.Invoke(*allArgs),self._olerepr_.defaultDispatchName,None) pywintypes.com_error: (-2147352562, '\xcd\xe5\xe4\xee\xef\xf3\xf1\xf2\xe8\xec\xee\xe5 \xf7\xe8\xf1\xeb\xee \xef\xe0\xf0\xe0\xec\xe5\xf2\xf0\xee\xe2.', None, None) Any insight into this problem would be most appreciated. Regards, Denis V. Komarov ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1596989&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-11-08 09:14:22
|
Bugs item #1590399, was opened at 2006-11-04 11:12 Message generated for change (Settings changed) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1590399&group_id=78018 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: pythonwin Group: None Status: Open Resolution: None Priority: 9 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) >Summary: Refcounting / GIL problems (dual) Initial Comment: I wonder if the below patch possibly addresses a refcount/memory problem. Think its possible, that DODECREF(this) frees <*this> from memory, another released threads malloc uses the memory and this->virtualInst is bogus? ( In preceding function ui_assoc_object::DoKillAssoc there is a simlar technique to do "PyObject *vi = virtualInst;" - but for reverse reason ) ( I'm still in search of memory leaks/crashes on dual cores and fast CPUs when other threads are going on parallel to win32ui GUI mainthread. ) --- win32assoc.cpp.orig 2005-04-12 17:01:00.000000000 +0200 +++ win32assoc.cpp 2006-11-04 10:59:46.326646400 +0100 @@ -252,9 +252,10 @@ { if (this==NULL) return NULL; if (virtualInst) { + PyObject *vi = virtualInst; + DOINCREF(vi); DODECREF(this); - DOINCREF(virtualInst); - return virtualInst; + return vi; } else return this; } ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-08 10:12 Message: Logged In: YES user_id=972995 Meanwhile there is significant feedback that c_GIL_bugs.patch in fact solved all the crash problems with threaded apps on all (dual core) machines. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-05 21:00 Message: Logged In: YES user_id=972995 In attachment a patch candidate I've so far in action for all these things. (That issue around "pExistingAppObject" was nonsense. pExistingAppObject seems to be not set to anything at all) Notes: The speed DECREF's in ~CVirtualHelper are switched all off by this patch - as it seems to not be valid so outside of the GIL. Would require a __asm LOCK INC/DEC or so. Have not seen serious speed issues in apps so far. Yet I've seen: most often CVirtualHelp is instanciated - costing a enter/leave python state switch - and then immediately a helper.call(..) with again a enter/leave state switch. If optimization necessary, possibly by a CVirtualHelpE does it which enters Python in constructor until destruction and the .call's do not again have to enter. Only few locations, where the intermediate PythonLeave/GUI_BGN_SAVE is necessary. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-04 16:49 Message: Logged In: YES user_id=972995 Think I found other serious potential refcount/GIL problems which cause crashes here in apps with threads - mainly on dual core - and set priority to 9: I looked over GUI_BGN_SAVE's => Py_XINC/DECREF's outside of the GIL. this causes probably the special problems only on dual cores when multiple threads: win32cmdui/Line120: GUI_BGN_SAVE; Python_delete_assoc(ob); GUI_END_SAVE; win32uimodule/Line650: void Python_delete_assoc( void *ob ) { // Notify Python object of my attached object removal. { CVirtualHelper helper ("OnAttachedObjectDeath", ob); <================ helper.call(); <================ } ui_assoc_object *pObj; if ((pObj=ui_assoc_object::GetPyObject(ob)) && !bInFatalShutdown) { CEnterLeavePython _celp; // KillAssoc requires it is held! pObj->KillAssoc(); } } win32virt.cpp/Line22 CVirtualHelper::CVirtualHelper(const char *iname, const void *iassoc, EnumVirtualErrorHandling veh/* = VEH_PRINT_ERROR */) { handler=NULL; py_ob = NULL; ... py_ob = py_bob; Py_INCREF(py_ob); <================ // Py_XINCREF(handler); } The gross hack for speed in CVirtualHelper::~CVirtualHelper() will not work for dual cores. A fast "ZDODECREF/ZDODECREF" independent of GIL (unless it went to 0) would be possible on x86 with "__asm LOCK DEC <(op)->ob_refcnt>" or so. see: http://groups.google.de/group/comp.lang.python/msg/ef530d4448814391 CVirtualHelper::~CVirtualHelper() { // XXX - Gross hack for speed. This is called for eachh window message // so only grabs the Python lock if the objects need Python, if ((retVal && retVal->ob_refcnt==1) || <================ DECREF not atomic on multi-core CPU's (handler && handler->ob_refcnt==1) || (py_ob && py_ob->ob_refcnt==1)) { CEnterLeavePython _celp; XDODECREF(retVal); XDODECREF(handler); XDODECREF(py_ob); } else { XDODECREF(retVal); <================ DECREF not atomic on multi-core CPU's XDODECREF(handler); XDODECREF(py_ob); } } Maybe there are other loose INCREFS / DECREFS in win32 code? And I found - probably most serious in this list - : Only CVirtualHelper::do_call is CEnterLeavePython protected: BOOL CVirtualHelper::do_call(PyObject *args) { CEnterLeavePython _celp; XDODECREF(retVal); // our old one. retVal = NULL; but all entrace call functions are not - but they are bulding up Python Values ! Think that is serious (even on single cores where I have very rare crashes): e.g.: BOOL CVirtualHelper::call() { if (!handler) return FALSE; PyObject *arglst = Py_BuildValue("()"); <================ return do_call(arglst); } =>Probably the CEnterleave protection should be moved out of do_call to all entrance call(...)'s & call_args() ? Looked in a rush over the 200 base DECREFs in Pythonwin. Found so far no other smelling refcounting. Only maybe this is invalid : --- win32app.cpp.orig 2006-01-10 15:38:00.000000000 +0100 +++ win32app.cpp 2006-11-04 16:44:24.009694400 +0100 @@ -412,6 +412,7 @@ { PyCWinThread::cleanup(); // total hack! - while (pExistingAppObject) + while (pExistingAppObject->ob_refcnt>1) DODECREF(pExistingAppObject); // this may delete it. + DODECREF(pExistingAppObject); } ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-04 11:22 Message: Logged In: YES user_id=972995 (repeated) --- win32assoc.cpp.orig 2005-04-12 17:01:00.000000000 +0200 +++ win32assoc.cpp 2006-11-04 10:59:46.326646400 +0100 @@ -252,9 +252,10 @@ { if (this==NULL) return NULL; if (virtualInst) { + PyObject *vi = virtualInst; + DOINCREF(vi); DODECREF(this); - DOINCREF(virtualInst); - return virtualInst; + return vi; } else return this; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1590399&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
