Comment 13 for bug 915015

Can't figure out how to reproduce it, sorry.

This line in the backtrace:

#15 0x08098972 in connection_force_close_cb (source=0x9d0b560, res=0x9d236f0,
user_data=0x9910c10) at wocky-c2s-porter.c:1257

tells us that this was an unclean disconnection. My thinking was that we need a vcard cache entry with ->vcard_node, ->pipeline_item, and ->pending_requests to be NULL in order for the code in cache_entry_attempt_to_free() which modifies the hash table to fire, so I tried requesting a vCard, sending back an error of type='wait' to tell it to try again later, and then uncleanly disconnecting the connection in a variety of ways… but no dice.

I did make the surprising discovery that if I change connect/stream-closed.py to send a spurious stanza right before the </stream:stream>:

- # server closes its stream
+ # server tells us it hates us then closes the stream cleanly.
+ stream.send(
+ elem('message', from_='lol@localhost')(
+ elem('body')(u'piss off')
+ ))
     stream.sendFooter()

then the test fails! Gabble never sends the corresponding </stream:stream>. The issue seems to be related to the state transitions of WockyXmppConnection at the end of a stream when it gets a blob of data containing both a stanza and the </stream:stream> — if you stick a q.expect('dbus-signal', signal='MessageReceived') before sendFooter(), the test passes. But I couldn't track it down further. :(

So I am donating these bugs back to the public domain.