View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001814 | GNUnet | obsolete | public | 2011-09-30 20:01 | 2024-05-03 14:02 |
| Reporter | viric | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Platform | x86_64 | OS | linux | OS Version | linux |
| Product Version | Git master | ||||
| Summary | 0001814: assertion failures on gnunet-peerinfo, rev 17144 | ||||
| Description | Listing my peers with 'gnunet-peerinfo': $ gnunet-peerinfo Peer `6EIB04HE2M9HODUJJ1P12BF2VB9576RTT222DIV76E02G202KD00M5NB40VS4AVM8AIK09R7TTMFGP23BJ55RAP93803G8H97NBT34G' Peer `AE46QIBQC7K5M1MC8DU0UE23O1R2B6FHDUPFACN622G5PA970HR2D2R2LG7FEBND04BQQI0J8974RHACVPVAVV1HON3RTKCTKG1IIH8' Peer `BP61JTKRVRED0B96VJ8OTB0TR7SVISLMULSIPMN5AOR7FDK0PARU111JGLACHCT5LDI0DAIC6MHIN1MQ4AJGD9GAILEKO18DVIOB0QG' set 30 19:58:59-293919 gnunet-peerinfo-5398 ERROR Assertion failed at connection.c:647. set 30 19:58:59-294529 gnunet-peerinfo-5398 ERROR Assertion failed at connection.c:647. Peer `CR4TG54SSF018DU09264S2THPA8O4MHINOP8KU9SDPLR9PMIS72F6JK12HQP26672V9VJJETICUR21HIGS1GFGM40UM3TCJB4BRJ6P0' ........ | ||||
| Steps To Reproduce | Running a bit later, worked. | ||||
| Tags | No tags attached. | ||||
|
|
'try_connect_using_address' would invoke 'connect_fail_continuation' if it was invoked with the end-of-list (addr==NULL) and was no pending address for testing (ap_head==NULL) in the queue: if (addr == NULL) { h->dns_active = NULL; if (NULL == h->ap_head) connect_fail_continuation (h); return; } However, this code neglects the possibility that an address was returned, validated *extremely* quickly (removal from ap_head, h->sock becomes non-NULL) and only then the last DNS result is returned. This is atypical since the resolution for the 'localhost' addresses is all done in the same task. With actual DNS (done out-of-process), this can happen depending on how tasks are scheduled (explaining why this is non-deterministic and rare). The 'connect_fail_continuation' then has a weak assertion failure (not sure what else might go wrong from there, given that both the 'success' and 'failure' continuations are invoked). |
|
|
Solution is simple: check for 'h->sock' being non-NULL and simply NOT call the 'connect_fail_continuation' in this case (the 'success' continuation should already be active anyway). Fixed in SVN 17150. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-09-30 20:01 | viric | New Issue | |
| 2011-10-03 00:36 | Christian Grothoff | Note Added: 0004674 | |
| 2011-10-03 00:36 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2011-10-03 00:36 | Christian Grothoff | Status | new => assigned |
| 2011-10-03 00:38 | Christian Grothoff | Note Added: 0004675 | |
| 2011-10-03 00:39 | Christian Grothoff | Status | assigned => resolved |
| 2011-10-03 00:39 | Christian Grothoff | Fixed in Version | => Git master |
| 2011-10-03 00:39 | Christian Grothoff | Resolution | open => fixed |
| 2011-10-04 13:22 | Christian Grothoff | Target Version | => 0.9.0pre4 |
| 2011-10-21 09:38 | Christian Grothoff | Fixed in Version | Git master => 0.9.0pre4 |
| 2011-10-31 12:00 | Christian Grothoff | Status | resolved => closed |
| 2024-05-03 14:02 | Christian Grothoff | Category | peerinfo service => obsolete |
