[python-win32] Fw: [ pywin32-Bugs-3292681 ] adodbapi - Subtle crash

[Mark Hammond]

On 29/04/2011 7:07 AM, Vernon Cole wrote:
> I found two fixes for the crash.  Now I need one of you brilliant folks
> to tell me which is correct. First, here is a snippet from adodbapi.
> Look closely at the comments on the last three lines of code ...
> v v v v v v v v v
>     def _closeAdoConnection(self):                  #all v2.1 Rose
> """close the underlying ADO Connection object,
>             rolling it back first if it supports transactions."""
>          if self.supportsTransactions:
>              self.adoConn.RollbackTrans()
>          self.adoConn.Close()
>
>      def close(self):
>          self.messages=[]
>          try:
>              self._closeAdoConnection()                      #v2.1 Rose
>          except (Exception), e:
>              self._raiseConnectionError(InternalError,e)
>
>          del self.adoConn                                       ####
> adding this line cures the crash
>
> #### or
>          pythoncom.CoUninitialize()                        #### removing
> this line cures the crash
> ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
>
> So --- which is the correct correction?
> remove the CoUininitialize()
> or perform the explicit del of the Dispatch object?

It sounds like the problem is that the object is still alive once 
CoUninitialize() is called - then, when the adoCon object is finally 
released (when the Connection object itself is released) "bad things" 
(tm) happen.  I think that is likely to be considered expected behaviour 
- things should all be released before doing a CoUninitialize().

I'd suggest that something like self.adoConn = None in one of the close 
methods is perfectly reasonable.   OTOH, I expect the benefits of 
uninitializing are probably fairly small, so never uninitializing will 
probably not cause any problems.  Resetting the object to None (or 
del'ing it) is probably preferred though - if the object remains alive 
and is cleaned up while the Python interpreter is finalizing I'd expect 
things could still go wrong, and discarding the object completely at 
close time seems sensible anyway.

If you can give me a connection string that is likely to fail for me, I 
can run the example in a debug version of Python and check there isn't 
some other bug in pywin32 or similar which could mitigate the entire 
issue...

Thanks!

Mark