2018-09-18 15:10 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005393GNUnetcadet servicepublic2018-08-22 14:08
Reporterch3 
Assigned Toch3 
PrioritynormalSeverityminorReproducibilitysometimes
StatusresolvedResolutionno change required 
Product VersionSVN HEAD 
Target Version0.11.0Fixed in Version 
Summary0005393: Receiving message on destroyed channel
DescriptionIn the rps service:
Other peer establishes new channel (connect handler was called).
Other peer establishes new channel (connect handler was called) a second time.
From rps service point of view, this should not happen. So the old channel is destroyed. (See report 0005392.)
The disconnect handler was called on the younger channel.
The context of this channel was destroyed in turn. (More precisely: It was destroyed on another event that triggered the destruction. If the channel would have still been around, that would have been evident from the logs at that point.)
A message handler on one of the destroyed channels was called. (Either the one that was destroyed by the other peer or the one that was destroyed by the rps service in turn to the double establishment of channels. Which one is - due to lacking context - not evident.)
An assertion was triggered because the context to the channel is missing.
Steps To ReproduceRun rps service in some way.
Additional InformationObserved during run of rps-profiler:

rps-20636 ERROR Assertion failed at gnunet-service-rps.c:1816. Aborting.

Previous logs:
Jul 05 19:11:01-756907 rps-20636 DEBUG New channel was established to us (Peer DDNX).
Jul 05 19:11:01-756931 rps-20636 DEBUG Peer DDNX is live and valid, calling 1 pending operations on it
Jul 05 19:11:01-756945 rps-20636 DEBUG Removing pending liveliness check for peer DDNX

[...]

Jul 05 19:13:04-241964 rps-20636 DEBUG New channel was established to us (Peer DDNX).
Jul 05 19:13:04-241994 rps-20636 DEBUG Peer DDNX is live and valid, calling 0 pending operations on it
Jul 05 19:13:04-242011 rps-20636 INFO Destroying channel due to GNUNET_CADET_channel_destroy()
Jul 05 19:13:04-242026 rps-20636 DEBUG Callback on destruction of recv-channel was called (DDNX)
Jul 05 19:13:04-242038 rps-20636 DEBUG Peer is NOT in the process of being destroyed
Jul 05 19:13:04-242049 rps-20636 DEBUG Peer DDNX destroyed recv channel - cleaning up channel

[...]

Jul 05 19:13:06-877816 rps-20636 DEBUG Callback on destruction of send-channel was called (DDNX)
Jul 05 19:13:06-877848 rps-20636 DEBUG Peer is NOT in the process of being destroyed
Jul 05 19:13:06-877861 rps-20636 DEBUG send channel (DDNX) was destroyed - cleaning up

[...]

Jul 05 19:13:15-576114 rps-20636 DEBUG Received CHECK_LIVE (DDNX)
Jul 05 19:13:15-576176 rps-20636 ERROR Assertion failed at gnunet-service-rps.c:1816. Aborting.
TagsNo tags attached.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]
+Relationships

-Notes

~0013141

ch3 (developer)

This is probably working as supposed:
It may happen, that messages arrive after the other peer destroyed the channel.
Deal with it.
+Notes

-Issue History
Date Modified Username Field Change
2018-07-05 21:40 ch3 New Issue
2018-07-05 21:40 ch3 Status new => assigned
2018-07-05 21:40 ch3 Assigned To => Bart Polot
2018-07-07 00:26 Christian Grothoff Target Version => 0.11.0
2018-07-11 00:23 ch3 Note Added: 0013141
2018-07-11 00:24 ch3 Assigned To Bart Polot => ch3
2018-08-22 14:08 ch3 Status assigned => resolved
2018-08-22 14:08 ch3 Resolution open => no change required
+Issue History