View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007029||GNUnet||DHT service||public||2021-10-05 20:45||2021-12-31 09:26|
|Reporter||md||Assigned To||Christian Grothoff|
|Platform||GNU/Linux||OS||Guix System||OS Version||v???|
|Summary||0007029: Assertion failure in get_target_peers (when allocating rtargets)|
|Description||When testing the "http://localhost:8089/search-dht" form of Scheme-GNUnet,|
gnunet-service-dht crashed with the following message:
okt 05 20:07:27-878394 dht-25189 ERROR Assertion failed at gnunet-service-dht_neighbours.c:1181. Aborting.
Looking at gnunet-service-dht_neighbours.c:1181, that's
rtargets = GNUNET_new_array (ret,
struct PeerInfo *);
so maybe 'ret' was to large? 'ret' is assigned by:
ret = get_forward_count (hop_count,
so maybe get_forward_count returns a too large result?
Curiously, the crash only happens if the replication level is zero, and not if it is one.
Also note that that the network size (according to $GNUB/gnunet-nse) is 1:
1633458666879901 1,000000 0,000000 -nan
and ‘target_value’ is:
1 + (target_replication - 1.0) / (GDS_NSE_get ()
+ ((float) (target_replication - 1.0)
So for target_replication=0, target_value = 1 - 1/(0 + (1 - 1) * hop_count) = 1 - 1/0 = some kind of infinity (or NaN?).
(GDS_NSE_get() is (an approximation of) the logarithm of the network size, so it is approx. equal to 0 here).
So target_value becomes infinity (or, allowing for numerical issues, at least very large in magnitude).
Then the forward count is set to
forward_count = (uint32_t) target_value
I don't know what is the result of casting an infinity or NaN to an integral type, but I wouldn't recommend it. Maybe it can be very large?
|Steps To Reproduce||For developing/testing Scheme-GNUnet, I run the following services: dht, statistics, core, nse and peerinfo (no ARM!).|
|Tags||No tags attached.|
My calculation for target_replication=0 and GDS_NSE_get()=0 is bogus, it should be
target_value = 1 - 1/(0 + -1* hop_count)= 1 + 1/hop_count.
However, an infinity is still possible if hop_count = 0. I don't know if that can happen though.
||Seems likely. Still, how did you end up with a target_replication of 0?|
||Fix committed to master branch.|
||e173017ed..6ef071b8c fixes the crash by forcing the target_replication to be in a 'sane' range. Still wonder how 0 appeared, but at least the crash should be fixed now.|
The example mini-application I'm writing allows choosing any replication level, including 0. I'll look into making the minimum level 1!
Unfortunately, Mantis doesn't allow commenting on resolves issues, so I had to reopen the issue.
||I see. Ok, that explains it then. reopening: no problem. I'll consider this resolved then.|
|2021-10-05 20:45||md||New Issue|
|2021-10-06 12:19||Christian Grothoff||Assigned To||=> Christian Grothoff|
|2021-10-06 12:19||Christian Grothoff||Status||new => assigned|
|2021-10-06 16:36||md||Note Added: 0018428|
|2021-10-06 18:51||Christian Grothoff||Note Added: 0018429|
|2021-10-06 18:53||Christian Grothoff||Changeset attached||=> gnunet master 6ef071b8|
|2021-10-06 18:53||Christian Grothoff||Note Added: 0018430|
|2021-10-06 18:53||Christian Grothoff||Status||assigned => resolved|
|2021-10-06 18:53||Christian Grothoff||Resolution||open => fixed|
|2021-10-06 18:54||Christian Grothoff||Note Added: 0018431|
|2021-10-06 19:02||md||Status||resolved => feedback|
|2021-10-06 19:02||md||Resolution||fixed => reopened|
|2021-10-06 19:02||md||Note Added: 0018432|
|2021-10-06 19:07||Christian Grothoff||Note Added: 0018433|
|2021-10-06 19:07||Christian Grothoff||Status||feedback => resolved|
|2021-10-06 19:07||Christian Grothoff||Fixed in Version||=> 0.15.4|
|2021-10-10 20:17||schanzen||Target Version||=> 0.15.4|
|2021-12-31 09:26||schanzen||Target Version||0.15.4 => 0.16.0|