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 | ||
| Priority | high | Severity | major | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | Git master | ||||
| 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. | ||||
| related to | 0003910 | closed | Christian Grothoff | Various core assertions related to neighbours unexpectely not found in neighbour map |
|
|
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. |
| 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 |
