|
From: SourceForge.net <no...@so...> - 2009-12-03 16:52:07
|
Bugs item #2908261, was opened at 2009-12-03 17:52 Message generated for change (Tracker Item Submitted) made by sreichelt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&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: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
