pywin32-bugs Mailing List for Python for Windows Extensions (Page 94)
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...> - 2004-11-11 02:27:23
|
Bugs item #1054585, was opened at 2004-10-27 02:35 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054585&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kim Davies (kjd) Assigned to: Nobody/Anonymous (nobody) Summary: MFC71.DLL missing from install? Initial Comment: Pythonwin Build 203 for Python 2.4 (using b1) doesn't start, it exits on launch with this dialog box: "This application has failed to start because MFC71.DLL was not found. Re-installing the application may fix this problem." Previous versions of Pythonwin have worked fine on the machine, but this is the first time a 20x build has been used. System in Windows XP SP2. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-11-11 15:27 Message: Logged In: YES user_id=552329 This is a dupe of: [ 1016558 ] 202 Windows Installer requires MSVCR71.dll http://sourceforge.net/tracker/index.php?func=detail&aid=1016558&group_id=78018&atid=551954 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054585&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-10 20:01:03
|
Bugs item #1063508, was opened at 2004-11-10 00:24 Message generated for change (Comment added) made by jodyburns You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063508&group_id=78018 Category: win32 Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Jody Burns (jodyburns) Assigned to: Nobody/Anonymous (nobody) Summary: LockFileEx does not return outcome of lock operation Initial Comment: When win32file.LockFileEx is called, it returns None instead of the success/failure of the lock operation. When used with non-blocking locks it is impossible to tell if a lock has succeeded or not. I have attached a program demonstrating this behavior. When the program is run, it attempts to lock itself but has no way of knowing it the lock succeeded. ---------------------------------------------------------------------- >Comment By: Jody Burns (jodyburns) Date: 2004-11-10 20:01 Message: Logged In: YES user_id=308517 Ah, you are correct. Sorry to bother you and thanks for your assistance. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-11-10 08:22 Message: Logged In: YES user_id=14198 Like most other pywin32 functions, this one raises an exception of the API call fails. The operation succeeded if it did not raise win32file.error. Let me know (and re-open the bug) if I misunderstood. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063508&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-10 16:01:41
|
Bugs item #1063888, was opened at 2004-11-10 09:30 Message generated for change (Settings changed) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063888&group_id=78018 Category: com Group: None >Status: Closed Resolution: Invalid Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Can't import win32comext submodules Initial Comment: I'm running Build 203 on Python 2.3 although the CVS browser indicates this is probably a problem with all builds. 'import win32comext.mapi.mapi' failed. The quick fix was to add a blank __init__.py file to the win32comext directory, although it could also be done in the registry I think. Let me know if you need a patch file for the __init__.py file. ;-) ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2004-11-10 10:00 Message: Logged In: YES user_id=699438 Disregard, I realized that 'import win32com.mapi.mapi' does the trick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063888&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-10 16:00:27
|
Bugs item #1063888, was opened at 2004-11-10 09:30 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063888&group_id=78018 Category: com Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Can't import win32comext submodules Initial Comment: I'm running Build 203 on Python 2.3 although the CVS browser indicates this is probably a problem with all builds. 'import win32comext.mapi.mapi' failed. The quick fix was to add a blank __init__.py file to the win32comext directory, although it could also be done in the registry I think. Let me know if you need a patch file for the __init__.py file. ;-) ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2004-11-10 10:00 Message: Logged In: YES user_id=699438 Disregard, I realized that 'import win32com.mapi.mapi' does the trick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063888&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-10 15:30:04
|
Bugs item #1063888, was opened at 2004-11-10 09:30 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=1063888&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Can't import win32comext submodules Initial Comment: I'm running Build 203 on Python 2.3 although the CVS browser indicates this is probably a problem with all builds. 'import win32comext.mapi.mapi' failed. The quick fix was to add a blank __init__.py file to the win32comext directory, although it could also be done in the registry I think. Let me know if you need a patch file for the __init__.py file. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063888&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-10 08:22:10
|
Bugs item #1063508, was opened at 2004-11-10 11:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063508&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jody Burns (jodyburns) Assigned to: Nobody/Anonymous (nobody) Summary: LockFileEx does not return outcome of lock operation Initial Comment: When win32file.LockFileEx is called, it returns None instead of the success/failure of the lock operation. When used with non-blocking locks it is impossible to tell if a lock has succeeded or not. I have attached a program demonstrating this behavior. When the program is run, it attempts to lock itself but has no way of knowing it the lock succeeded. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-11-10 19:22 Message: Logged In: YES user_id=14198 Like most other pywin32 functions, this one raises an exception of the API call fails. The operation succeeded if it did not raise win32file.error. Let me know (and re-open the bug) if I misunderstood. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063508&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-10 00:24:58
|
Bugs item #1063508, was opened at 2004-11-10 00:24 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=1063508&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jody Burns (jodyburns) Assigned to: Nobody/Anonymous (nobody) Summary: LockFileEx does not return outcome of lock operation Initial Comment: When win32file.LockFileEx is called, it returns None instead of the success/failure of the lock operation. When used with non-blocking locks it is impossible to tell if a lock has succeeded or not. I have attached a program demonstrating this behavior. When the program is run, it attempts to lock itself but has no way of knowing it the lock succeeded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1063508&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-05 03:51:00
|
Bugs item #1053745, was opened at 2004-10-26 00:03 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018 Category: installation Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Oliver Giesen (ogiesen) Assigned to: Nobody/Anonymous (nobody) Summary: PythonPath no longer set by installer. Initial Comment: I have meant to report this ever since the first 20x release but somehow never got around to it: Before the 20x releases the installer used to add the extensions to the PythonPath as sub-entries win32 and win32com respectively. This no longer is the case and as a result my WinCvs macros that make use of the extensions no longer work unless I add the extensions to the PythonPath manually. Is there something I have missed? Is there some other way to make the extensions "publicly importable" nowadays? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-11-05 14:50 Message: Logged In: YES user_id=14198 It was removed as it causes problems when multiple installations of Python exist on the same machine. If one application wants to include a 'private' Python in their application directory, the global registry screws things. Removing these registry settings have solved many problems for people. If wincvs is using its own Python, then the current behaviour is unfortunately correct. There should be a way to specify what dir you want to install pywin32 in, but there isn't. The solution is to simply copy those pywin32 directories, and the .pth file (which has relative paths) to the cygwin python's site-packages directory. If cygwin is using the "global" Python, then it probably means cygwin is preventing site.py from running - this is what locates and processes the .pth files. I'm happy to help you resolve this, but am very unlikely to move back to the registry. ---------------------------------------------------------------------- Comment By: Oliver Giesen (ogiesen) Date: 2004-11-01 19:47 Message: Logged In: YES user_id=158827 Yes, that file is there and it does obviously get taken into account when I run Python scripts via python.exe, however, that's not what I do most of the time. Most of the time my scripts are run via Python23.dll (as macros embedded in WinCvs) and AFAICT that does not take into account the pywin32.pth file. This only works if the path is actually set in the PythonPath registry key, i.e. HKLM\SOFTWARE\Python\PythonCore\2.3\PythonPath . I'm simply a bit confused because I'm really sure that I never had to manually edit the PythonPath with the pre-200 installers. Was there a specific reason why this functionality has been removed from the installers? Or could this be a problem of the way WinCvs embeds Python? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-26 09:04 Message: Logged In: YES user_id=14198 There should be a pywin32.pth file installed into your site-packages directory. Python loads this as it starts up - unless you have told Python not to process site.py You should be able to confirm this by running python.exe and printing sys.path ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-03 16:02:34
|
Bugs item #1058686, was opened at 2004-11-02 14:40 Message generated for change (Comment added) made by abondarenko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1058686&group_id=78018 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Andrey Bondarenko (abondarenko) Assigned to: Nobody/Anonymous (nobody) Summary: PyPumpWaitingMessages return 0 if no messages Initial Comment: According documentation PumpWaitingMessages will return 0 only if WM_QUIT have received. I've found that win32gui.PumpWaitingMessages return 0 if there was no messages in queue. In file win32gui.i in definition of PyPumpWaitingMessages defined "long result = 0". If messages haven't received, result will not altered, so function will return 0. ---------------------------------------------------------------------- >Comment By: Andrey Bondarenko (abondarenko) Date: 2004-11-03 21:02 Message: Logged In: YES user_id=1150380 Sorry my mistake ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1058686&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-02 09:40:14
|
Bugs item #1058686, was opened at 2004-11-02 14:40 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=1058686&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Bondarenko (abondarenko) Assigned to: Nobody/Anonymous (nobody) Summary: PyPumpWaitingMessages return 0 if no messages Initial Comment: According documentation PumpWaitingMessages will return 0 only if WM_QUIT have received. I've found that win32gui.PumpWaitingMessages return 0 if there was no messages in queue. In file win32gui.i in definition of PyPumpWaitingMessages defined "long result = 0". If messages haven't received, result will not altered, so function will return 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1058686&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-11-01 08:47:17
|
Bugs item #1053745, was opened at 2004-10-25 16:03 Message generated for change (Comment added) made by ogiesen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018 Category: installation Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Oliver Giesen (ogiesen) Assigned to: Nobody/Anonymous (nobody) Summary: PythonPath no longer set by installer. Initial Comment: I have meant to report this ever since the first 20x release but somehow never got around to it: Before the 20x releases the installer used to add the extensions to the PythonPath as sub-entries win32 and win32com respectively. This no longer is the case and as a result my WinCvs macros that make use of the extensions no longer work unless I add the extensions to the PythonPath manually. Is there something I have missed? Is there some other way to make the extensions "publicly importable" nowadays? ---------------------------------------------------------------------- >Comment By: Oliver Giesen (ogiesen) Date: 2004-11-01 09:47 Message: Logged In: YES user_id=158827 Yes, that file is there and it does obviously get taken into account when I run Python scripts via python.exe, however, that's not what I do most of the time. Most of the time my scripts are run via Python23.dll (as macros embedded in WinCvs) and AFAICT that does not take into account the pywin32.pth file. This only works if the path is actually set in the PythonPath registry key, i.e. HKLM\SOFTWARE\Python\PythonCore\2.3\PythonPath . I'm simply a bit confused because I'm really sure that I never had to manually edit the PythonPath with the pre-200 installers. Was there a specific reason why this functionality has been removed from the installers? Or could this be a problem of the way WinCvs embeds Python? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-26 01:04 Message: Logged In: YES user_id=14198 There should be a pywin32.pth file installed into your site-packages directory. Python loads this as it starts up - unless you have told Python not to process site.py You should be able to confirm this by running python.exe and printing sys.path ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-27 21:47:42
|
Bugs item #1054982, was opened at 2004-10-27 11:08 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054982&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: 江文 (jiangwen365) Assigned to: Nobody/Anonymous (nobody) Summary: Ver 203 does not work with Plone/Zope Initial Comment: Hello All, I installed Pywin203 on my zope 2.73's python installation, and it's not really a exciting experience to me. As I start Zope from Plone control panel or from windoes service panel, windows will pop up a error message titled "PythonService.exe - Entry Point Not Found" and saying "The procedure entry point ? PyWinObject_AsDEVMODE@YAHPAU_object@@PAPAU_de vicemodeA@@H@Z could not be located in the dynamic link library pywintype23.dll." After trying many times, I had to go back to Pywin201, then everything worked as nothing had happened. Any suggestion? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-28 07:47 Message: Logged In: YES user_id=14198 This isn't really our bug - Zope comes with a version of pywin32, and attempting to upgrade part of it will always fail. You should be able to get things working by replacing any existing pywintypes23.dll with the one in build 203. It is expected that the next build of Zope/Plone will come bundled with pywin-203, rather than the (IIRC) 163 build it comes with now. ---------------------------------------------------------------------- Comment By: 江文 (jiangwen365) Date: 2004-10-27 13:56 Message: Logged In: YES user_id=1147025 Or may be it is a Zope bug issue? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054982&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-27 03:56:10
|
Bugs item #1054982, was opened at 2004-10-27 01:08 Message generated for change (Comment added) made by jiangwen365 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054982&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: 江文 (jiangwen365) Assigned to: Nobody/Anonymous (nobody) Summary: Ver 203 does not work with Plone/Zope Initial Comment: Hello All, I installed Pywin203 on my zope 2.73's python installation, and it's not really a exciting experience to me. As I start Zope from Plone control panel or from windoes service panel, windows will pop up a error message titled "PythonService.exe - Entry Point Not Found" and saying "The procedure entry point ? PyWinObject_AsDEVMODE@YAHPAU_object@@PAPAU_de vicemodeA@@H@Z could not be located in the dynamic link library pywintype23.dll." After trying many times, I had to go back to Pywin201, then everything worked as nothing had happened. Any suggestion? ---------------------------------------------------------------------- >Comment By: 江文 (jiangwen365) Date: 2004-10-27 03:56 Message: Logged In: YES user_id=1147025 Or may be it is a Zope bug issue? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054982&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-27 01:08:27
|
Bugs item #1054982, was opened at 2004-10-27 01: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=1054982&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: 江文 (jiangwen365) Assigned to: Nobody/Anonymous (nobody) Summary: Ver 203 does not work with Plone/Zope Initial Comment: Hello All, I installed Pywin203 on my zope 2.73's python installation, and it's not really a exciting experience to me. As I start Zope from Plone control panel or from windoes service panel, windows will pop up a error message titled "PythonService.exe - Entry Point Not Found" and saying "The procedure entry point ? PyWinObject_AsDEVMODE@YAHPAU_object@@PAPAU_de vicemodeA@@H@Z could not be located in the dynamic link library pywintype23.dll." After trying many times, I had to go back to Pywin201, then everything worked as nothing had happened. Any suggestion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054982&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-26 13:35:52
|
Bugs item #1054585, was opened at 2004-10-26 21: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=1054585&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kim Davies (kjd) Assigned to: Nobody/Anonymous (nobody) Summary: MFC71.DLL missing from install? Initial Comment: Pythonwin Build 203 for Python 2.4 (using b1) doesn't start, it exits on launch with this dialog box: "This application has failed to start because MFC71.DLL was not found. Re-installing the application may fix this problem." Previous versions of Pythonwin have worked fine on the machine, but this is the first time a 20x build has been used. System in Windows XP SP2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1054585&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-25 23:04:07
|
Bugs item #1053745, was opened at 2004-10-26 00:03 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018 Category: installation Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Oliver Giesen (ogiesen) Assigned to: Nobody/Anonymous (nobody) Summary: PythonPath no longer set by installer. Initial Comment: I have meant to report this ever since the first 20x release but somehow never got around to it: Before the 20x releases the installer used to add the extensions to the PythonPath as sub-entries win32 and win32com respectively. This no longer is the case and as a result my WinCvs macros that make use of the extensions no longer work unless I add the extensions to the PythonPath manually. Is there something I have missed? Is there some other way to make the extensions "publicly importable" nowadays? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-26 09:04 Message: Logged In: YES user_id=14198 There should be a pywin32.pth file installed into your site-packages directory. Python loads this as it starts up - unless you have told Python not to process site.py You should be able to confirm this by running python.exe and printing sys.path ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-25 14:03:16
|
Bugs item #1053745, was opened at 2004-10-25 16:03 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=1053745&group_id=78018 Category: installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Giesen (ogiesen) Assigned to: Nobody/Anonymous (nobody) Summary: PythonPath no longer set by installer. Initial Comment: I have meant to report this ever since the first 20x release but somehow never got around to it: Before the 20x releases the installer used to add the extensions to the PythonPath as sub-entries win32 and win32com respectively. This no longer is the case and as a result my WinCvs macros that make use of the extensions no longer work unless I add the extensions to the PythonPath manually. Is there something I have missed? Is there some other way to make the extensions "publicly importable" nowadays? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-24 18:28:27
|
Bugs item #1048355, was opened at 2004-10-16 17:30 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 8 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: PyCWnd.DestroyWindow causes memory access & stack faults Initial Comment: (b203 and all previous builds I know) win32ui does or causes indirectly something odd with memory in PyCWnd.DestroyWindow or WM_NCDESTROY handling. I watch this problem for years with different win32ui based apps, yet I'm afraid that I cannot manage to deliver a reproducable minimalistic crashing app, though I tried. Its a nasty stochastical memory damage problem I think. I can reproduce the crash here with different bigger apps in different situations. Now I have one where I manage to crash it >90% and did 100's of tests to isolate the problem and track it down. Thus I found it to be caused (here) by a PyCWnd.DestroyWindow call, but the actual crash takes place far later when the operative message handler has returned to the message loop. Some damage in memory. Some users maybe know that PythonWin itself sometimes crashes over the year at the end of some sessions, when debug windows were open or complex (own) window situations or randomly. Maybe there is a connection to the windows destroying & memory problem here. I'm quite sure there is a unresolved nasty bug in the DestroyWindow Process or with WM_NCDESTROY handling in win32ui. (Think is doesn't have to do with bug 906305 - in ui_window_destroy_window there is no CEnterLeave.. but GUI_BGN_SAVE/END_SAVE which seem to be correct ) I tell what I know about the bug: - I use win32ui for some GUI based tools since years. I get occasional crashes on certain window and non-modal dialog closings in different situations. memory problems of other code can be excluded. I traced it down to certain window destroyings going on - latest crash traces with registers far below (b203/py2.3.4), yet that will probably not tell much as there are indirect memory effects - the example code snipet below is the final handler of a autocompletion drop-down SysListCtrl32 in PyCFrameWnd: Upon certain key events the window has to be destroyed explicitely and after that some simple computation/and pasting to clipboard occurs - then return to message loop When self.aclstbase.DestroyWindow() is really done then in certain memory constellations the app crashes. Its very sensitive and abviously random. E.g. when i start the app and use it to a certain extent, then the bug will not show for long etc etc. Yet when alternative self.aclstbase.PostMessage(WM_CLOSE) is used in that case, the app crashes never ever in that situation. - the memory address of access fault changes in reproducible cases, when more or less python computations are done after the .DestroyWindow(). - The crash bug is more often on my Win98 than my WinXP - maybe because there is less memory .... - In other apps (mainly on my Win98) similar problems occur, when progress dialogs (non-modal) are destroyed or certain othe non-modal dialogs with commctrl childs. -In other apps (mainly on my Win98) a crash when multiple modal dialogs have the same parent and one is closed manually. - I think there are always other complex childs (window.Wnd hooked) inside the window/dialog that shows the closing crash. If its a simple plain dialog/window the bug maybe doesn't show at all (but Im not sure) - Always when the suspicios .DestroyWindow() or manual window closing methods call can be replaces by PostMessage(WM_CLOSE) or PostWM_USER- or timer-delayed .DestroyWindow() the crash can be 99%..100% (not completely sure) eliminated. Unfortunately .DestroyWindow() cannot be replaced always. Suspicions/Guesses: - Certain things are going on with the invalid CWnd* after DestroyWindow - Cannot oversee this - Problem when WM_NCDESTROY is handled. ( not sure if make sens but when I run a certain bigger app window (lots of childs and toolbars in) and do on the open mainframe the following >>> mainframe.SendMessage(wc.WM_DESTROY) 0 >>> mainframe.SendMessage(wc.WM_NCDESTROY) 0 ...Window focus change to still existing mainframe -> crash. Think no matter if it makes sense, win32ui should not raise a seg fault.?) - Invalide Message Routing / Calling ( the crash is always from win32ui at bottom of the call stack one or 3 or 2 calls later (randomly going somewhere into the open memory) ) - ThreadState Problems (Yet I reproduce the bug in apps with no extra threads or so going on) - Py/C AttachObject/Detach Problem ( Yet I played around on CmdTarget._obj_ level. The problem seems not to be there. ) My debugging knowledge not enough to find out more for now. I could make suggested tests in the crashing apps+computers if that helps? The bug is a constant, rare but unforseable instability problem with many of my tools. ########### def AutoCompleteTake(self,sn=None): .... #cleanup auto-c window ##self.aclstbase.PostMessage(WM_CLOSE) self.aclstbase.DestroyWindow() ... ############## (b203/py2.3.4 stack traces memory access errors after crash) MFC42! 73d99c2a() WIN32UI! 1002a268() MFC42! 73d99c2a() WIN32UI! 1002a268() 008253dc() WIN32UI! 0117f7b8() 8801129b() MFC42! 73d332fe() WIN32UI! 0117f7b8() MFC42! 73d332fb() WIN32UI! 0117f7b8() EAX = 00000000 EBX = 007A075A ECX = 01499FD8 EDX = 00000000 ESI = 0012F4CC EDI = 01499FD8 EIP = 73D332FB ESP = 0012F0C8 EBP = 0012F0F0 EFL = 00000206 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 0038 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=0 AC=0 PE=1 CY=0 00000014 = ???????? ST0 = -0.14695186589127226e+1843 ST1 = +0.00000000000000000e+0000 ST2 = +4.30166298621518843e+3581 ST3 = +0.00000000000000000e+0000 ST4 = +0.00000000000000000e+0000 ST5 = +2.10999965667724609e-0001 ST6 = +0.00000000000000000e+0000 ST7 = +0.00000000000000000e+0000 CTRL = 027F STAT = 4020 TAGS = FFFF EIP = 1E04B200 CS = 001B DS = 0023 EDO = 0012E3E0 ---------------------------------------------------------------------- >Comment By: Robert Kiendl (kxroberto) Date: 2004-10-24 20:28 Message: Logged In: YES user_id=972995 After getting a debug version of win32ui work, I found the location of the problem in my case (see below) and a temporary patch of win32uiExt.h. The Error was in the second location: OnNotify; the change in OnCmdMsg is just a analog guess (reasonable?). Maybe there are even more Python-callback occasions after which a destroyed window causes mem.acces errors. My guess: A Pythonic Notification Handler destroys the Window itself with .DestroyWindow() [and also the child yielding the notification]. Then the CWnd's "this" or the window handle or whatever become invalid/unusable and T::OnNotify crashes. Yet I have no complete overview why. My patch maybe only cures the symptom on a high level.? Maybe there are even more Python-callback calls after which a destroyed window can cause mem.acces errors? Don't know if adalx's hook-less windowproc solution also cures the problem. Also dont know if there is still another problem with WM_NCDESTROY? Yet, so far all my obscure win32ui window handling crashes (as described) disapeared and lately maybe I can fullfill my statement to a collage: Pythonic MFC apps never crash hard but only yield pleasant python exceptions... cvs diff win32uiExt.h (in directory C:\devel\pywin\pywin32\Pythonwin\) Index: win32uiExt.h =================================================================== RCS file: /cvsroot/pywin32/pywin32/Pythonwin/win32uiExt.h,v retrieving revision 1.5 diff -r1.5 win32uiExt.h 70c70,72 < else --- > else { > if (!IsWindow( this->m_hWnd )) > return TRUE; 71a74 > } 77c80,82 < else --- > else { > if (!IsWindow( ((NMHDR*)lParam)->hwndFrom )) > return TRUE; 78a84 > } *****CVS exited normally with code 1***** MSVC6++ Debugger stopped here (2nd function from top of stack): -------- virtual BOOL OnNotify (WPARAM wParam, LPARAM lParam, LRESULT *pResult) { // yield to Python first if (Python_OnNotify (this, wParam, lParam, pResult)) return TRUE; else ====> return T::OnNotify (wParam, lParam, pResult); } MFC42! 73d332fb() CPythonWndFramework<CFrameWnd>::OnNotify(CPythonWndFramework<CFrameWnd> * const 0x00e8ef38 {CPythonWndFramework<CFrameWnd> hWnd=0x0082558c}, unsigned int 1943215600, long 777, long * 0x0012f4cc) line 78 + 10 bytes MFC42! 73d31df0() MFC42! 73d31cea() MFC42! 73d31c73() MFC42! 73d31bfb() MFC42! 73d31bba() USER32! 77d13a50() USER32! 77d13b1f() USER32! 77d144f5() USER32! 77d14525() NTDLL! 77f65da3() USER32! 77d154b4() COMCTL32! 773156f8() COMCTL32! 773272ed() COMCTL32! 77327406() USER32! 77d13a50() USER32! 77d13b1f() USER32! 77d15b2c() USER32! 77d15f73() MFC42! 73d320f2() MFC42! 73d31d01() MFC42! 73d31c73() MFC42! 73d31bfb() MFC42! 73d31bba() USER32! 77d13a50() USER32! 77d13b1f() USER32! 77d13d79() USER32! 77d14374() ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2004-10-21 00:54 Message: Logged In: YES user_id=1067739 Since I can't upload the patch here I'll put it into the Patches section. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-20 02:11 Message: Logged In: YES user_id=14198 I'd be interested in a look at the patch. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2004-10-20 01:48 Message: Logged In: YES user_id=1067739 WM_NCDESTROY is handled in a funny way by Pythonwin. Actually, if I recall correctly, ALL messages are handled differently that you would normally expect in a MFC app. Messages are not received the usual way, using MFC message handlers. Instead a Windows message hook is installed which intercepts messages and dispatches them. I also had problems because WM_NCDESTORY, but they were of a different nature (so I remember). To solve them I removed the message hooks (which the Platform SDK says it can significantly slow you down) and converted win32ui to use normal message dispatching. This was kind of hard and I'm not sure I did it 100% correctly. If you want, I can make a patch against pywin32 build 203 for you to try and see if it solves your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-22 18:48:08
|
Bugs item #986673, was opened at 2004-07-07 15:54 Message generated for change (Comment added) made by prittenh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=986673&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 6 Submitted By: Phil Rittenhouse (prittenh) Assigned to: Mark Hammond (mhammond) Summary: Python exceptions through COM custom interface Initial Comment: The problem occurs with Python COM servers raising COM exceptions across a custom interface. Using the dispatch interface works fine, but in the custom interface the exception's error information is lost. The problem appears to be in PyGatewayBase::InterfaceSupportsErrorInfo() in PyGatewayBase.cpp. It is called to determine whether the GetErrorInfo API should be used to extract an error after an error HRESULT is returned from an interface. The function is passed an IID of an interface, the code compares this to the return value of GetIID() which is always IID_IUnknown. The comparison fails, so the function returns S_FALSE and no error info is extracted. The comment above the definition of GetIID() says: // Currently this is used only for ISupportErrorInfo, // so hopefully this will never be called in this base class. // (however, this is not a rule, so we wont assert or anything!) But it appears that it is called in the base class (or at least not overloaded by anyone inheriting from it). Everything seems to work fine if you just change InterfaceSupportsErrorInfo() to always return S_OK. ---------------------------------------------------------------------- >Comment By: Phil Rittenhouse (prittenh) Date: 2004-10-22 18:48 Message: Logged In: YES user_id=601682 My colleague David has created a simple COM server and client to demonstrate the issue (see attached). The Python COM server is fairly generic with one method that simply raises an exception. The C# client connects to the COM server via the custom interface and displays the results returned from the COM exception. Our workaround of always returning S_OK from InterfaceSupportsErrorInfo() may not be the best solution. Perhaps the more relevant question for me to ask is why does GetIID() always returns IID_IUnknown in this situation? Thanks for your help, Phil ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-08 23:45 Message: Logged In: YES user_id=14198 What do you mean by "custom interface" in this context? A custom interface should be implemented such that GetIID() returns other than IUnknown. The ISupportErrorInfo semantics indicate we do need to check the IID. I'll need more specific details. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=986673&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-21 12:53:21
|
Bugs item #1051453, was opened at 2004-10-21 04:53 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=1051453&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: win32pdhutil.browse broken (intentionally?) Initial Comment: The win32pdhutil.browse function no longer displays a dialog as documented in the "Python Programming on Win32" book. Looking at the CVS history, revision 1.6 removed the call to win32pdh.BrowseCounters and the subsequent "def test():" declaration, so that the code which was in the test function is now in browse. I'm wondering if this was an accident, since browse still takes the same parameters, but it doesn't use them. If the change was intentional, I think some comment explaining it is in order, especially since BrowseCounters still seems to work just fine given the parameters browse was giving it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1051453&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-20 23:19:03
|
Patches item #1051122, was opened at 2004-10-21 02:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1051122&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Removed Windows message hook Initial Comment: This is an EXPERIMENTAL patch. It could break existing applications. One major change is that the default message handler is no longer called always as the HookMessage help page tells you. This is required sometimes (when handling WM_GETMINMAXINFO for example). In those cases use something like this: res = self.WindowProc(message, wParam, lParam). Another change is that now the value returned by your Python handler will be passed back to Windows. So please return an integer (usually 0) as required by the specific message you handle. Not returning an integer still works, through. Detailed changes: Added pResult parameter to Python_check_message in which it puts the handler return value. Made old CPythonWndFramework::WindowProc a special case of a new one which now dispatches messages to the Python handlers and deletes associations on WM_NCDESTROY. Disabled message hooking in HookWindowsMessages and message processing in Win32uiPreTranslateMessage. PyCWnd::DoKillAssoc now checks if the window was already detached before calling UnsubclassWindow. For an unknown reason this is necessary after the changes above. Added PyCWnd.WindowProc method which calls the underlying MFC one. Fixed Python_OnCmdMsg to not call the command handler if pHandlerInfo != NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1051122&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-20 22:54:04
|
Bugs item #1048355, was opened at 2004-10-16 18:30 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 8 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: PyCWnd.DestroyWindow causes memory access & stack faults Initial Comment: (b203 and all previous builds I know) win32ui does or causes indirectly something odd with memory in PyCWnd.DestroyWindow or WM_NCDESTROY handling. I watch this problem for years with different win32ui based apps, yet I'm afraid that I cannot manage to deliver a reproducable minimalistic crashing app, though I tried. Its a nasty stochastical memory damage problem I think. I can reproduce the crash here with different bigger apps in different situations. Now I have one where I manage to crash it >90% and did 100's of tests to isolate the problem and track it down. Thus I found it to be caused (here) by a PyCWnd.DestroyWindow call, but the actual crash takes place far later when the operative message handler has returned to the message loop. Some damage in memory. Some users maybe know that PythonWin itself sometimes crashes over the year at the end of some sessions, when debug windows were open or complex (own) window situations or randomly. Maybe there is a connection to the windows destroying & memory problem here. I'm quite sure there is a unresolved nasty bug in the DestroyWindow Process or with WM_NCDESTROY handling in win32ui. (Think is doesn't have to do with bug 906305 - in ui_window_destroy_window there is no CEnterLeave.. but GUI_BGN_SAVE/END_SAVE which seem to be correct ) I tell what I know about the bug: - I use win32ui for some GUI based tools since years. I get occasional crashes on certain window and non-modal dialog closings in different situations. memory problems of other code can be excluded. I traced it down to certain window destroyings going on - latest crash traces with registers far below (b203/py2.3.4), yet that will probably not tell much as there are indirect memory effects - the example code snipet below is the final handler of a autocompletion drop-down SysListCtrl32 in PyCFrameWnd: Upon certain key events the window has to be destroyed explicitely and after that some simple computation/and pasting to clipboard occurs - then return to message loop When self.aclstbase.DestroyWindow() is really done then in certain memory constellations the app crashes. Its very sensitive and abviously random. E.g. when i start the app and use it to a certain extent, then the bug will not show for long etc etc. Yet when alternative self.aclstbase.PostMessage(WM_CLOSE) is used in that case, the app crashes never ever in that situation. - the memory address of access fault changes in reproducible cases, when more or less python computations are done after the .DestroyWindow(). - The crash bug is more often on my Win98 than my WinXP - maybe because there is less memory .... - In other apps (mainly on my Win98) similar problems occur, when progress dialogs (non-modal) are destroyed or certain othe non-modal dialogs with commctrl childs. -In other apps (mainly on my Win98) a crash when multiple modal dialogs have the same parent and one is closed manually. - I think there are always other complex childs (window.Wnd hooked) inside the window/dialog that shows the closing crash. If its a simple plain dialog/window the bug maybe doesn't show at all (but Im not sure) - Always when the suspicios .DestroyWindow() or manual window closing methods call can be replaces by PostMessage(WM_CLOSE) or PostWM_USER- or timer-delayed .DestroyWindow() the crash can be 99%..100% (not completely sure) eliminated. Unfortunately .DestroyWindow() cannot be replaced always. Suspicions/Guesses: - Certain things are going on with the invalid CWnd* after DestroyWindow - Cannot oversee this - Problem when WM_NCDESTROY is handled. ( not sure if make sens but when I run a certain bigger app window (lots of childs and toolbars in) and do on the open mainframe the following >>> mainframe.SendMessage(wc.WM_DESTROY) 0 >>> mainframe.SendMessage(wc.WM_NCDESTROY) 0 ...Window focus change to still existing mainframe -> crash. Think no matter if it makes sense, win32ui should not raise a seg fault.?) - Invalide Message Routing / Calling ( the crash is always from win32ui at bottom of the call stack one or 3 or 2 calls later (randomly going somewhere into the open memory) ) - ThreadState Problems (Yet I reproduce the bug in apps with no extra threads or so going on) - Py/C AttachObject/Detach Problem ( Yet I played around on CmdTarget._obj_ level. The problem seems not to be there. ) My debugging knowledge not enough to find out more for now. I could make suggested tests in the crashing apps+computers if that helps? The bug is a constant, rare but unforseable instability problem with many of my tools. ########### def AutoCompleteTake(self,sn=None): .... #cleanup auto-c window ##self.aclstbase.PostMessage(WM_CLOSE) self.aclstbase.DestroyWindow() ... ############## (b203/py2.3.4 stack traces memory access errors after crash) MFC42! 73d99c2a() WIN32UI! 1002a268() MFC42! 73d99c2a() WIN32UI! 1002a268() 008253dc() WIN32UI! 0117f7b8() 8801129b() MFC42! 73d332fe() WIN32UI! 0117f7b8() MFC42! 73d332fb() WIN32UI! 0117f7b8() EAX = 00000000 EBX = 007A075A ECX = 01499FD8 EDX = 00000000 ESI = 0012F4CC EDI = 01499FD8 EIP = 73D332FB ESP = 0012F0C8 EBP = 0012F0F0 EFL = 00000206 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 0038 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=0 AC=0 PE=1 CY=0 00000014 = ???????? ST0 = -0.14695186589127226e+1843 ST1 = +0.00000000000000000e+0000 ST2 = +4.30166298621518843e+3581 ST3 = +0.00000000000000000e+0000 ST4 = +0.00000000000000000e+0000 ST5 = +2.10999965667724609e-0001 ST6 = +0.00000000000000000e+0000 ST7 = +0.00000000000000000e+0000 CTRL = 027F STAT = 4020 TAGS = FFFF EIP = 1E04B200 CS = 001B DS = 0023 EDO = 0012E3E0 ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2004-10-21 01:54 Message: Logged In: YES user_id=1067739 Since I can't upload the patch here I'll put it into the Patches section. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-20 03:11 Message: Logged In: YES user_id=14198 I'd be interested in a look at the patch. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2004-10-20 02:48 Message: Logged In: YES user_id=1067739 WM_NCDESTROY is handled in a funny way by Pythonwin. Actually, if I recall correctly, ALL messages are handled differently that you would normally expect in a MFC app. Messages are not received the usual way, using MFC message handlers. Instead a Windows message hook is installed which intercepts messages and dispatches them. I also had problems because WM_NCDESTORY, but they were of a different nature (so I remember). To solve them I removed the message hooks (which the Platform SDK says it can significantly slow you down) and converted win32ui to use normal message dispatching. This was kind of hard and I'm not sure I did it 100% correctly. If you want, I can make a patch against pywin32 build 203 for you to try and see if it solves your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-20 00:11:44
|
Bugs item #1048355, was opened at 2004-10-17 01:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 8 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: PyCWnd.DestroyWindow causes memory access & stack faults Initial Comment: (b203 and all previous builds I know) win32ui does or causes indirectly something odd with memory in PyCWnd.DestroyWindow or WM_NCDESTROY handling. I watch this problem for years with different win32ui based apps, yet I'm afraid that I cannot manage to deliver a reproducable minimalistic crashing app, though I tried. Its a nasty stochastical memory damage problem I think. I can reproduce the crash here with different bigger apps in different situations. Now I have one where I manage to crash it >90% and did 100's of tests to isolate the problem and track it down. Thus I found it to be caused (here) by a PyCWnd.DestroyWindow call, but the actual crash takes place far later when the operative message handler has returned to the message loop. Some damage in memory. Some users maybe know that PythonWin itself sometimes crashes over the year at the end of some sessions, when debug windows were open or complex (own) window situations or randomly. Maybe there is a connection to the windows destroying & memory problem here. I'm quite sure there is a unresolved nasty bug in the DestroyWindow Process or with WM_NCDESTROY handling in win32ui. (Think is doesn't have to do with bug 906305 - in ui_window_destroy_window there is no CEnterLeave.. but GUI_BGN_SAVE/END_SAVE which seem to be correct ) I tell what I know about the bug: - I use win32ui for some GUI based tools since years. I get occasional crashes on certain window and non-modal dialog closings in different situations. memory problems of other code can be excluded. I traced it down to certain window destroyings going on - latest crash traces with registers far below (b203/py2.3.4), yet that will probably not tell much as there are indirect memory effects - the example code snipet below is the final handler of a autocompletion drop-down SysListCtrl32 in PyCFrameWnd: Upon certain key events the window has to be destroyed explicitely and after that some simple computation/and pasting to clipboard occurs - then return to message loop When self.aclstbase.DestroyWindow() is really done then in certain memory constellations the app crashes. Its very sensitive and abviously random. E.g. when i start the app and use it to a certain extent, then the bug will not show for long etc etc. Yet when alternative self.aclstbase.PostMessage(WM_CLOSE) is used in that case, the app crashes never ever in that situation. - the memory address of access fault changes in reproducible cases, when more or less python computations are done after the .DestroyWindow(). - The crash bug is more often on my Win98 than my WinXP - maybe because there is less memory .... - In other apps (mainly on my Win98) similar problems occur, when progress dialogs (non-modal) are destroyed or certain othe non-modal dialogs with commctrl childs. -In other apps (mainly on my Win98) a crash when multiple modal dialogs have the same parent and one is closed manually. - I think there are always other complex childs (window.Wnd hooked) inside the window/dialog that shows the closing crash. If its a simple plain dialog/window the bug maybe doesn't show at all (but Im not sure) - Always when the suspicios .DestroyWindow() or manual window closing methods call can be replaces by PostMessage(WM_CLOSE) or PostWM_USER- or timer-delayed .DestroyWindow() the crash can be 99%..100% (not completely sure) eliminated. Unfortunately .DestroyWindow() cannot be replaced always. Suspicions/Guesses: - Certain things are going on with the invalid CWnd* after DestroyWindow - Cannot oversee this - Problem when WM_NCDESTROY is handled. ( not sure if make sens but when I run a certain bigger app window (lots of childs and toolbars in) and do on the open mainframe the following >>> mainframe.SendMessage(wc.WM_DESTROY) 0 >>> mainframe.SendMessage(wc.WM_NCDESTROY) 0 ...Window focus change to still existing mainframe -> crash. Think no matter if it makes sense, win32ui should not raise a seg fault.?) - Invalide Message Routing / Calling ( the crash is always from win32ui at bottom of the call stack one or 3 or 2 calls later (randomly going somewhere into the open memory) ) - ThreadState Problems (Yet I reproduce the bug in apps with no extra threads or so going on) - Py/C AttachObject/Detach Problem ( Yet I played around on CmdTarget._obj_ level. The problem seems not to be there. ) My debugging knowledge not enough to find out more for now. I could make suggested tests in the crashing apps+computers if that helps? The bug is a constant, rare but unforseable instability problem with many of my tools. ########### def AutoCompleteTake(self,sn=None): .... #cleanup auto-c window ##self.aclstbase.PostMessage(WM_CLOSE) self.aclstbase.DestroyWindow() ... ############## (b203/py2.3.4 stack traces memory access errors after crash) MFC42! 73d99c2a() WIN32UI! 1002a268() MFC42! 73d99c2a() WIN32UI! 1002a268() 008253dc() WIN32UI! 0117f7b8() 8801129b() MFC42! 73d332fe() WIN32UI! 0117f7b8() MFC42! 73d332fb() WIN32UI! 0117f7b8() EAX = 00000000 EBX = 007A075A ECX = 01499FD8 EDX = 00000000 ESI = 0012F4CC EDI = 01499FD8 EIP = 73D332FB ESP = 0012F0C8 EBP = 0012F0F0 EFL = 00000206 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 0038 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=0 AC=0 PE=1 CY=0 00000014 = ???????? ST0 = -0.14695186589127226e+1843 ST1 = +0.00000000000000000e+0000 ST2 = +4.30166298621518843e+3581 ST3 = +0.00000000000000000e+0000 ST4 = +0.00000000000000000e+0000 ST5 = +2.10999965667724609e-0001 ST6 = +0.00000000000000000e+0000 ST7 = +0.00000000000000000e+0000 CTRL = 027F STAT = 4020 TAGS = FFFF EIP = 1E04B200 CS = 001B DS = 0023 EDO = 0012E3E0 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-20 10:11 Message: Logged In: YES user_id=14198 I'd be interested in a look at the patch. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2004-10-20 09:48 Message: Logged In: YES user_id=1067739 WM_NCDESTROY is handled in a funny way by Pythonwin. Actually, if I recall correctly, ALL messages are handled differently that you would normally expect in a MFC app. Messages are not received the usual way, using MFC message handlers. Instead a Windows message hook is installed which intercepts messages and dispatches them. I also had problems because WM_NCDESTORY, but they were of a different nature (so I remember). To solve them I removed the message hooks (which the Platform SDK says it can significantly slow you down) and converted win32ui to use normal message dispatching. This was kind of hard and I'm not sure I did it 100% correctly. If you want, I can make a patch against pywin32 build 203 for you to try and see if it solves your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-19 23:48:22
|
Bugs item #1048355, was opened at 2004-10-16 18:30 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 8 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: PyCWnd.DestroyWindow causes memory access & stack faults Initial Comment: (b203 and all previous builds I know) win32ui does or causes indirectly something odd with memory in PyCWnd.DestroyWindow or WM_NCDESTROY handling. I watch this problem for years with different win32ui based apps, yet I'm afraid that I cannot manage to deliver a reproducable minimalistic crashing app, though I tried. Its a nasty stochastical memory damage problem I think. I can reproduce the crash here with different bigger apps in different situations. Now I have one where I manage to crash it >90% and did 100's of tests to isolate the problem and track it down. Thus I found it to be caused (here) by a PyCWnd.DestroyWindow call, but the actual crash takes place far later when the operative message handler has returned to the message loop. Some damage in memory. Some users maybe know that PythonWin itself sometimes crashes over the year at the end of some sessions, when debug windows were open or complex (own) window situations or randomly. Maybe there is a connection to the windows destroying & memory problem here. I'm quite sure there is a unresolved nasty bug in the DestroyWindow Process or with WM_NCDESTROY handling in win32ui. (Think is doesn't have to do with bug 906305 - in ui_window_destroy_window there is no CEnterLeave.. but GUI_BGN_SAVE/END_SAVE which seem to be correct ) I tell what I know about the bug: - I use win32ui for some GUI based tools since years. I get occasional crashes on certain window and non-modal dialog closings in different situations. memory problems of other code can be excluded. I traced it down to certain window destroyings going on - latest crash traces with registers far below (b203/py2.3.4), yet that will probably not tell much as there are indirect memory effects - the example code snipet below is the final handler of a autocompletion drop-down SysListCtrl32 in PyCFrameWnd: Upon certain key events the window has to be destroyed explicitely and after that some simple computation/and pasting to clipboard occurs - then return to message loop When self.aclstbase.DestroyWindow() is really done then in certain memory constellations the app crashes. Its very sensitive and abviously random. E.g. when i start the app and use it to a certain extent, then the bug will not show for long etc etc. Yet when alternative self.aclstbase.PostMessage(WM_CLOSE) is used in that case, the app crashes never ever in that situation. - the memory address of access fault changes in reproducible cases, when more or less python computations are done after the .DestroyWindow(). - The crash bug is more often on my Win98 than my WinXP - maybe because there is less memory .... - In other apps (mainly on my Win98) similar problems occur, when progress dialogs (non-modal) are destroyed or certain othe non-modal dialogs with commctrl childs. -In other apps (mainly on my Win98) a crash when multiple modal dialogs have the same parent and one is closed manually. - I think there are always other complex childs (window.Wnd hooked) inside the window/dialog that shows the closing crash. If its a simple plain dialog/window the bug maybe doesn't show at all (but Im not sure) - Always when the suspicios .DestroyWindow() or manual window closing methods call can be replaces by PostMessage(WM_CLOSE) or PostWM_USER- or timer-delayed .DestroyWindow() the crash can be 99%..100% (not completely sure) eliminated. Unfortunately .DestroyWindow() cannot be replaced always. Suspicions/Guesses: - Certain things are going on with the invalid CWnd* after DestroyWindow - Cannot oversee this - Problem when WM_NCDESTROY is handled. ( not sure if make sens but when I run a certain bigger app window (lots of childs and toolbars in) and do on the open mainframe the following >>> mainframe.SendMessage(wc.WM_DESTROY) 0 >>> mainframe.SendMessage(wc.WM_NCDESTROY) 0 ...Window focus change to still existing mainframe -> crash. Think no matter if it makes sense, win32ui should not raise a seg fault.?) - Invalide Message Routing / Calling ( the crash is always from win32ui at bottom of the call stack one or 3 or 2 calls later (randomly going somewhere into the open memory) ) - ThreadState Problems (Yet I reproduce the bug in apps with no extra threads or so going on) - Py/C AttachObject/Detach Problem ( Yet I played around on CmdTarget._obj_ level. The problem seems not to be there. ) My debugging knowledge not enough to find out more for now. I could make suggested tests in the crashing apps+computers if that helps? The bug is a constant, rare but unforseable instability problem with many of my tools. ########### def AutoCompleteTake(self,sn=None): .... #cleanup auto-c window ##self.aclstbase.PostMessage(WM_CLOSE) self.aclstbase.DestroyWindow() ... ############## (b203/py2.3.4 stack traces memory access errors after crash) MFC42! 73d99c2a() WIN32UI! 1002a268() MFC42! 73d99c2a() WIN32UI! 1002a268() 008253dc() WIN32UI! 0117f7b8() 8801129b() MFC42! 73d332fe() WIN32UI! 0117f7b8() MFC42! 73d332fb() WIN32UI! 0117f7b8() EAX = 00000000 EBX = 007A075A ECX = 01499FD8 EDX = 00000000 ESI = 0012F4CC EDI = 01499FD8 EIP = 73D332FB ESP = 0012F0C8 EBP = 0012F0F0 EFL = 00000206 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 0038 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=0 AC=0 PE=1 CY=0 00000014 = ???????? ST0 = -0.14695186589127226e+1843 ST1 = +0.00000000000000000e+0000 ST2 = +4.30166298621518843e+3581 ST3 = +0.00000000000000000e+0000 ST4 = +0.00000000000000000e+0000 ST5 = +2.10999965667724609e-0001 ST6 = +0.00000000000000000e+0000 ST7 = +0.00000000000000000e+0000 CTRL = 027F STAT = 4020 TAGS = FFFF EIP = 1E04B200 CS = 001B DS = 0023 EDO = 0012E3E0 ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2004-10-20 02:48 Message: Logged In: YES user_id=1067739 WM_NCDESTROY is handled in a funny way by Pythonwin. Actually, if I recall correctly, ALL messages are handled differently that you would normally expect in a MFC app. Messages are not received the usual way, using MFC message handlers. Instead a Windows message hook is installed which intercepts messages and dispatches them. I also had problems because WM_NCDESTORY, but they were of a different nature (so I remember). To solve them I removed the message hooks (which the Platform SDK says it can significantly slow you down) and converted win32ui to use normal message dispatching. This was kind of hard and I'm not sure I did it 100% correctly. If you want, I can make a patch against pywin32 build 203 for you to try and see if it solves your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-19 23:03:19
|
Patches item #1049836, was opened at 2004-10-19 18:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1049836&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Niki Spahiev (nikis) Assigned to: Nobody/Anonymous (nobody) Summary: makepy and reserved word propertyes Initial Comment: Prevent generating of propertyes with names which are reserved words ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-20 09:03 Message: Logged In: YES user_id=14198 Thanks! Checking in genpy.py; new revision: 1.44; previous revision: 1.43 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1049836&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
