View Issue Details

IDProjectCategoryView StatusLast Update
0004025GNUnettransport servicepublic2018-06-07 00:24
ReporterChristian GrothoffAssigned ToChristian Grothoff 
PriorityhighSeveritymajorReproducibilityrandom
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0004025: Supurious SEND_OK causes GNUNET_break (GNUNET_NO == n->is_ready); assertion in transport_api.c to fail
DescriptionThis is when the client receives a "SEND_OK" message, but didn't expect one.
Steps To ReproduceRunning a peer for a bit.
TagsNo tags attached.

Relationships

related to 0003910 closedChristian Grothoff Various core assertions related to neighbours unexpectely not found in neighbour map 

Activities

Christian Grothoff

2015-10-27 20:47

manager   ~0009811

Logging suggests that the service is really not generating duplicate SEND_OKs.

Christian Grothoff

2015-10-28 13:49

manager   ~0009815

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 (!).

Christian Grothoff

2015-10-28 13:50

manager   ~0009816

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.

Christian Grothoff

2015-10-28 14:06

manager   ~0009817

Fixed in SVN 36610.

Issue History

Date Modified Username Field Change
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