Created attachment 23807 [details]
With current Gabble master, some of the tube tests sporadically fail. I have attached accept-private-dbus-tube failing: it appears never to get s5b-connected.
I'll also attach the Gabble log but it's for the entire test suite run :(
Created attachment 23808 [details]
accept-private-dbus-tube failing in a different way!
Bugzilla wouldn't let me attach the full Gabble log. So I ran just this test in a loop, until it failed again (but this time it fails differently!). New test log attached; gabble log to follow.
Created attachment 23809 [details]
gabble log from the second attached test failure
First log is a failing in offer-private-stream-tube.py not accept-private-dbus-tube.
Looking at the code it doesn't seem to be a race so for some reason Gabble failed to connect to your SOCKS5 socket.
I've been able to reproduce the second issue (accept-private-dbus-tube.py). It seems that the s5b-connected is not fired but, according to Gabble log, Gabble properly connected to the socket. I have no idea why.
I wonder if this has the same cause as #22022. Sometimes the tests also time out on waiting for TransferredBytes to change.
Created attachment 32819 [details]
accept-private-dbus-tube race test log
In the accept-private-dbus-tube test, the code waits for the s5b-connected and AcceptDBusTube (through the expected_before argument) events with expect_many. It then expects to receive the s5b-data-received event with the auth request.
What's happening for me is it receives the s5b-connected event, but before it gets the AcceptDBusTube event, it receives the s5b-data-received event. The s5b-data-received event goes unhandled. Then after the AcceptDBusTube event is received, when it gets to where it expects the s5b-data-received event, it times out.
Attached is the excerpt from the test log illustrating this.
With 0.10.2 I am only suffering problems reported in bug 30565