On Thu, Jan 28, 2010 at 12:52:37PM -0600, Shawn Walker wrote: > On 01/28/10 12:48 PM, [email protected] wrote: > >On Thu, Jan 28, 2010 at 09:59:40AM -0800, Danek Duvall wrote: > >>[email protected] wrote: > >> > >>> http://cr.opensolaris.org/~johansen/webrev-14240/ > >> > >>Does this fix the problem, or just narrow the window of vulnerability? > >>That is, can the object be destroyed (or close() called) between the time > >>that self.__started is set to True and the time that the "curl object" is > >>placed on "this multi-stack" or whatever? > > > >You're right. This is a race. Not a logic error, as I originally > >thought. I've changed the synopsis, analysis, and fix for this bug > >accordingly. A new, smaller webrev is available here: > > > > http://cr.opensolaris.org/~johansen/webrev-14240-2/ > > > Seems right to me as well. I'm going to assume that if for some > bizarre reason that an exception was raised by remove_request that > it's ok that the lock isn't released.
I'll put a try/finally around this lock, just to be paranoid. What has me confused is that we hit this in __del__. I don't completely understand how it's possible that this object was being deleted at the same time that somebody was fiddling with its state on the multi-handle. My working theory is that its destruction was part of another exception, and that somewhere else in the transport a engine.reset() got called. External callers of reset must hold the transport lock, but I guess that since __del__ didn't have to, that's what caused our race and exception. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
