View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004025||GNUnet||transport service||public||2015-10-26 16:23||2018-06-07 00:24|
|Reporter||Christian Grothoff||Assigned To||Christian Grothoff|
|Platform||i7||OS||Debian GNU/Linux||OS Version||squeeze|
|Product Version||SVN HEAD|
|Target Version||0.11.0pre66||Fixed in Version||0.11.0pre66|
|Summary||0004025: Supurious SEND_OK causes GNUNET_break (GNUNET_NO == n->is_ready); assertion in transport_api.c to fail|
|Description||This is when the client receives a "SEND_OK" message, but didn't expect one.|
|Steps To Reproduce||Running a peer for a bit.|
|Tags||No tags attached.|
||Logging suggests that the service is really not generating duplicate SEND_OKs.|
Oct 28 12:15:16-200786 transport-api-1481 DEBUG Receiving SEND_OK message, transmission to W1CZ succeeded.
Oct 28 12:15:16-240879 transport-api-1481 DEBUG Received message of type 82 with 124 bytes from `W1CZ'.
Oct 28 12:15:17-437242 transport-api-1481 DEBUG At bandwidth 1365617 byte/s next transmission to W1CZ in 0 ms
Oct 28 12:15:17-441141 transport-api-1481 DEBUG Added 704 bytes of payload message for W1CZ after 3900 µs delay at 1365617 b/s
From the logs:
Oct 28 12:15:17-441430 transport-1489 DEBUG Received SEND request 181104 for `W1CZ' and first message of type 82 and total size 704
Oct 28 12:15:17-441763 transport-1489 DEBUG It took us 313 µs to send 704/704 bytes to W1CZ (1, tcp)
Oct 28 12:15:17-441872 transport-api-1481 DEBUG Receiving SEND_OK message, transmission to W1CZ succeeded.
Oct 28 12:15:18-180365 transport-1489 WARNING It took us 279 s to send 648/0 bytes to W1CZ (-1, tcp)
Oct 28 12:15:18-180803 transport-api-1481 DEBUG Receiving SEND_OK message, transmission to W1CZ failed.
This suggests that we might be dealing with a SEND_OK confirmation from a *previous* connection to the peer. If the message can sit idle/stale in the transport plugin for like 5 minutes (and on top of that failed to be transmitted in this case...), it is plausible that the connection was dropped and re-established.
handle_send_transmit_continuation was fixed to only send SEND_OK if the connection is "up", but that doesn't mean it is *still* up, it could be that it is *again* up with a different session (!).
||Inspection of the longer log suggests the pattern (unusually high delay, failed transmission) is the same in 4/4 cases of the assertion being triggered.|
||Fixed in SVN 36610.|
|2015-10-26 16:23||Christian Grothoff||New Issue|
|2015-10-26 16:23||Christian Grothoff||Status||new => assigned|
|2015-10-26 16:23||Christian Grothoff||Assigned To||=> Christian Grothoff|
|2015-10-26 16:26||Christian Grothoff||Relationship added||related to 0003910|
|2015-10-27 20:47||Christian Grothoff||Note Added: 0009811|
|2015-10-28 13:49||Christian Grothoff||Note Added: 0009815|
|2015-10-28 13:50||Christian Grothoff||Note Added: 0009816|
|2015-10-28 14:06||Christian Grothoff||Note Added: 0009817|
|2015-10-28 14:06||Christian Grothoff||Status||assigned => resolved|
|2015-10-28 14:06||Christian Grothoff||Fixed in Version||=> 0.11.0pre66|
|2015-10-28 14:06||Christian Grothoff||Resolution||open => fixed|
|2018-06-07 00:24||Christian Grothoff||Status||resolved => closed|