Maintained by: NLnet Labs

[Unbound-users] Potential Bug

Robert Fleischman
Wed Jun 29 16:32:23 CEST 2011


I said:

>> Potential Bug: In "mesh_state_cleanup", I noticed that
>> "comm_point_drop_reply" is called to remove unset replies, HOWEVER, it
>> does not appear that either "stats_dropped" is incremented or more
>> importantly "num_reply_addrs" is not decremented.    Doesn't this lack
>> of a decrement potentially cause the "16 times" limit go into effect and
>> prematurely drop queries?

Your response:

>The num_reply_addrs is decremented when a reply is sent (which can be an
>error if the mesh state is removed because of an error).  The
>mesh_state_cleanup indeed does not cleanup the num_reply_addrs value
>correctly, but this routine is only called from the mesh_state_delete
>function.  Thus it does not present a bug.

Okay, I agree.

Consider this:  Assume my Internet connection goes out for a bit, thus
no replies come
in, so, queries pile up quickly.

Consider the following code path during this outage:

mesh_new_client() -> mesh_make_new_space() -> Code in
mesh_make_new_space() decides jostle is needed ->
mesh_state_delete() -> mesh_state_cleanup()

That causes num_reply_addrs to NOT be decremented.

Now my Internet connection comes back, BUT, num_reply_addrs got so
high that the "16 times" limit goes into effect.  Now I get all my
queries dropped even though there is no error or problem anymore.

My temporary outage caused num_reply_addrs to grow and there is no way
for it to come back down.  So, I'm stuck dropping queries until a
restart of the server.

-Rob