[python-win32] Pythoncom error

[Emlyn Jones]

On 3/15/06, Mark Hammond <mhammond at skippinet.com.au> wrote:
> > Hello,
> > I'm stress testing an application I have written using the Python Asp
> > bindings, on occasions I get an ASP 0147 error (Internal Server
> > Error), In the IIS logs it manifests itself as a c0000005 trapable
> > error.
>
> That sounds like an Access Violation is happening - which probably is *not*
> directly related to the error below:
>
> >   File "C:\Python24\Lib\site-packages\win32comext\axdebug\adb.py",
> > line 262, in CloseApp
> >     self.appEventConnection.Disconnect()
> >   File "C:\Python24\Lib\site-packages\win32com\client\connect.py",
> > line 41, in Disconnect
> >     self.cp.Unadvise(self.cookie)
>
> This error is specific to the debugger support.  It would be safe to change
> line 262 of abd.py from:
>
>      self.cp.Unadvise(self.cookie)
> to:
>      try:
>          self.cp.Unadvise(self.cookie)
>      except pythoncom.com_error:
>          pass
>
> That *should* get you into the debugger OK - but it probably does not get
> you much closer to the original error.
>
> Another thing to try:
> * Change to win32comext\axscript\client
> * execute "pyscript.py --debug"
> * Start Pythonwin, and open the Tools -> Remote Collector Debugging Tool
> * Restart your app.
>
> You should see *lots* of stuff being spewed to Pythonwin as your app runs.
> When you app finally dies, the tail of this log might be interesting - eg,
> any tracebacks being displayed, or any evidence of death *inside* Python
> etc.
>
> Mark
>
Hi Mark, thanks for the reply.
Here's the thing; I took your advice and kept an eye out for errors
related to the debugger support and fixed them when I found them
(often with a just quick try except clause as you suggested, I'll
revisit them when I get time), there where three locations where the
debugger code raised exceptions. After making those changes my
application has become significantly more stable. Is it possible that
the debugger support code is running all the time, even when a
debugger is not attached? (Or that I am missing something and
"accidently" running a debugger, IIS is still a bit of a mystery to
me). How can I be 100% sure that the debug stuff is disabled?
As an example, One thing I have noticed is that I now get
"WARNING:Ignoring Keyboard Interrupt from scripting engine" and
everything continues as normal, I'm think that producing that warning
used to cause a raised exception and kill my app. Does any of this
sound feasible?
I'm still getting the original access violation (but I am seeing
proper debugger output) so there is an issue in my C extension code
but the difference in stability is siginificant.

Cheers,
Emlyn.