View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001814GNUnetobsoletepublic2011-09-30 18:012024-05-03 12:02
Reporterviric Assigned ToChristian Grothoff Due Date
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Platformx86_64OSlinuxOS Versionlinux
Product VersionGit master 
Summary0001814: assertion failures on gnunet-peerinfo, rev 17144
DescriptionListing 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 ReproduceRunning a bit later, worked.
TagsNo tags attached.

Activities

Christian Grothoff

2011-10-02 22:36

manager   ~0004674

'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).

Christian Grothoff

2011-10-02 22:38

manager   ~0004675

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.

Issue History

Date ModifiedUsernameFieldChange
2011-09-30 18:01viricNew Issue
2011-10-02 22:36Christian GrothoffNote Added: 0004674
2011-10-02 22:36Christian GrothoffAssigned To => Christian Grothoff
2011-10-02 22:36Christian GrothoffStatusnew => assigned
2011-10-02 22:38Christian GrothoffNote Added: 0004675
2011-10-02 22:39Christian GrothoffStatusassigned => resolved
2011-10-02 22:39Christian GrothoffFixed in Version => Git master
2011-10-02 22:39Christian GrothoffResolutionopen => fixed
2011-10-04 11:22Christian GrothoffTarget Version => 0.9.0pre4
2011-10-21 07:38Christian GrothoffFixed in VersionGit master => 0.9.0pre4
2011-10-31 11:00Christian GrothoffStatusresolved => closed
2024-05-03 12:02Christian GrothoffCategorypeerinfo service => obsolete