|
From: SourceForge.net <no...@so...> - 2009-12-04 22:42:43
|
Bugs item #2908261, was opened at 2009-12-04 03:52 Message generated for change (Comment added) made by mhammond 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: Pending 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 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-05 09:42 Message: It isn't clear to me how you are using pywin32 here - if it is a wx app which crashes, you are probably best off looking for help on the wx list ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-04 21:43 Message: I don't think I have any Python-implemented shell extensions installed, and looking at the DLLs that are loaded when the file dialog opens, I can't see anything related to Python. So I think the test case should hopefully work even on a clean Windows installation (oh - we are using Vista, btw - forgot that) with just Python, PyWin32, and wxPython. But: python26.dll, pythoncom26.dll, and pywintypes26.dll are never unloaded after the script exits. It's the same with an empty script, though. Does this already indicate a problem? Are we making a mistake in the way we use ActiveScript, maybe? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-04 08:45 Message: Do you have any Python implemented shell extensions (eg, Tortoise HG or Tortoise BZR?). I'd suggest you look in the debugger to try and work out if the file open dialog is causing another Python interpreter to be loaded into the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
