View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001801 | GNUnet | transport service | public | 2011-09-27 17:47 | 2011-09-30 13:01 |
| Reporter | Matthias Wachs | Assigned To | Matthias Wachs | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | Git master | ||||
| Summary | 0001801: Transport service does not notify clients about shutdown | ||||
| Description | Transport service does a shutdown Client waiting for GNUNET_TRANSPORT_notify_transmit_ready -> Assertion transport.api.c:379 GNUNET_assert (n->th!= NULL) Shouldn't transport service notify clients about shutdown in gnunet_transport_service.c : shutdown_task : GST_clients_stop ?? Current implementation: GST_clients_stop () { /* nothing to do */ } | ||||
| Steps To Reproduce | interrupt test_transport_api_reliability while running | ||||
| Tags | No tags attached. | ||||
|
|
OR but imho dangerous is client is really gone (and n->th freed): change transport_api.c to call callback static int neighbour_delete (void *cls, const GNUNET_HashCode * key, void *value) { struct GNUNET_TRANSPORT_Handle *handle = cls; struct Neighbour *n = value; if (NULL != handle->nd_cb) handle->nd_cb (handle->cls, &n->id); if (n->th != NULL) { GNUNET_TRANSPORT_notify_transmit_ready_cancel (n->th); n->th->notify(n->th->notify_cls, 0, NULL); } GNUNET_assert (NULL == n->th); |
|
|
The transport service is certainly not at fault here. It should NOT notify clients about the shutdown, the shutdown should look like a service crash to the clients -- and be handled nicely (by trying to re-connect with exponential back-off). |
|
|
Actually, looking at this more closely, the code at fault is neither the transport service nor transport_api, but the process using either! What is wrong is that the calling process (which is unfortunately NOT given in the report), must call "GNUNET_TRANSPORT_notify_transmit_ready_cancel" *during* the "handle->nd_cb" callback (also given above). So *during* the disconnect callback the client is expected to cancel pending requests. If the client fails to do so, we abort (assertion failure) because our API was violated. So --- which one was the process that died with this assertion failure to begin with? |
|
|
fixed in 17135 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-09-27 17:47 | Matthias Wachs | New Issue | |
| 2011-09-27 17:47 | Matthias Wachs | Status | new => assigned |
| 2011-09-27 17:47 | Matthias Wachs | Assigned To | => Matthias Wachs |
| 2011-09-27 17:50 | Matthias Wachs | Note Added: 0004631 | |
| 2011-09-27 17:50 | Matthias Wachs | Status | assigned => feedback |
| 2011-09-27 20:49 | Christian Grothoff | Note Added: 0004632 | |
| 2011-09-29 00:57 | Christian Grothoff | Note Added: 0004642 | |
| 2011-09-30 13:00 | Matthias Wachs | Note Added: 0004661 | |
| 2011-09-30 13:00 | Matthias Wachs | Status | feedback => assigned |
| 2011-09-30 13:01 | Matthias Wachs | Status | assigned => closed |
| 2011-09-30 13:01 | Matthias Wachs | Resolution | open => fixed |
