[rfc] [patch] sftp unit tests without ssh

[John A Meinel]

John A Meinel wrote:
> Robey Pointer wrote:
>> On 25 Jan 2006, at 10:57, John A Meinel wrote:
>>
>>> Robey Pointer wrote:
>>>> On 24 Jan 2006, at 12:00, John Arbash Meinel wrote:
>>>>
>>>>> However, after merging you I get:
>>>>> ~bzr: WARNING: Exception from within unit test server thread:
>>>>> <socket.error instance at 0xb6b6894c>
>>>>> ~bzr: WARNING: Exception from within unit test server thread:
>>>>> <socket.error instance at 0xb6b68bac>
>>>>> ~bzr: WARNING: Exception from within unit test server thread:
>>>>> <socket.error instance at 0xb6b6582c>
>>>>>
>>>>> Probably we should also us 'log_exception_quietly()' which puts a
>>>>> traceback into ~/.bzr.log, which would help debug this.
>>>> I see these sometimes, though I can't reproduce them right now (probably
>>>> laptop slowness).  log_exception_quietly() won't help much, because the
>>>> logs are erased right after each test, so you'll never see the
>>>> exception. :)
>>>>
>>>> I think the error is just a shutdown synchronization problem: one side
>>>> closing before the other is finished.  Probably the unit test's
>>>> destructors abruptly closing sockets that the server thinks are still in
>>>> play -- which is why the don't cause the test to fail.  Maybe we should
>>>> just catch and squelch socket.errors, but I wish I could catch one in
>>>> the act just to make sure.
>>> You could always print the traceback to sys.stdout.
>>> traceback.print_exc() works just fine. Only run_bzr is setup to redirect
>>> sys.stdout.
>> Of course, I was able to reproduce this minutes after I sent the email.
>> :)  Turns out that it's just a socket.error from a failed write after
>> the socket is closed, so it's harmless.  I checked in the attached patch
>> to my bzr.dev.sftp branch to squelch the warning.
>>
>> robey
>>
>>
> 
> Is it a time when we are trying to write to a closed socket? Like on the
> client side we got an exception an exited, rather than continuing?
> 
> I'm just worried that if we catch all socket exceptions and throw them
> away, we might miss future bugs.
> 
>> ------------------------------------------------------------------------
>>
>> === modified file 'bzrlib/transport/sftp.py'
>> --- bzrlib/transport/sftp.py
>> +++ bzrlib/transport/sftp.py
>> @@ -896,9 +896,13 @@
>>          self._socket.close()
>>          try:
>>              self._callback(s, self.stop_event)
>> +        except socket.error:
>> +            pass
>>          except Exception, x:
>>              # probably a failed test
>>              warning('Exception from within unit test server thread: %r' % x)
>> +            import traceback
>> +            warning(traceback.format_exc())
>>  
>>      def stop(self):
>>          self.stop_event.set()
>>
> 
> Why is self._callback() writing to the socket? Since we just did
> _socket.close() it seems the real bug lies in something writing to the
> socket.
> So either we fix the callbacks, or we move self._socket.close() after
> calling the callback.

Looking closer into this, you of course call the callback after closing
the socket, since you only want one connection.
So the question becomes, why are we writing after the connection is
closed? The callback is typically 'run_server()', so it seems like the
client is just disconnecting before the server finishes.

Does socket.error have any more specific information, so we can detect
"connection closed" or something like that? I would really prefer a
specific error trap, rather than an unspecified one.

John
=:->



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060126/8cab0ece/attachment.pgp