[Unbound-users] Potential Bug

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 06/30/2011 05:10 PM, lst_hoe02 at kwsoft.de wrote:
> Zitat von "W.C.A. Wijngaards" <wouter at NLnetLabs.nl>:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Robert,
>>
>> On 06/29/2011 04:59 PM, W.C.A. Wijngaards wrote:
>>> Hi Robert,
>>>
>>> On 06/29/2011 04:32 PM, Robert Fleischman wrote:
>>>> 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.
>>>
>>> You are correct, and I was wrong.  It should be fixed.
>>>
>>> Thanks for the report (and persistence :-) )
>>
>> Fixed in the svn trunk development of unbound.
>>
>> This code path is triggered by jostled queries.  It is not triggered by
>> ordinary timeouts or servfails.
> 
> So it is not included in 1.4.11 ?

No, that was released yesterday morning.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJODW/dAAoJEJ9vHC1+BF+NTJwP/iVL+ANNn5kFjY6t1mKMKD3t
2CnuaLrAEO9KcjiDTowAk/HdQuw/Dwdv+Jm0NtSwntM0Ypz7/azfaCxv9lI4IyVO
r6eRaXbuL7yK99ROrBZQtYnvgx6cJbpTagJJlX9QwMdxXm/G8ZCx1PnZ3skmJHzB
UAE/+rSsgTnV4CamK9iYJR6msy0+oM/iYsDUKhAgV0G4bndBCdRtkUece2tFZWRy
XwWmmzWn5/kg455ciVb8wo7gJayiyhj7a20Zw/YuMDLGVCYmLYbZDSxNBLur91+F
guqyzz3Hkzl8HzDeA5cVf2BlEfwL/oWATixZXC0C4KBtp/LgXIGyZLn/xHN7T7EP
X+24cv9gC7skxCsgEoTtvJWsL+LsMmuI+BDjM/zIlWb0/TnhaTrwJyoDPyT+tD3A
HU2d2DgpwhwBCLdtqa0aXFxlOXSYSnuRCBOE/GcBYRR9KSXRlJxAxxSm9Q5CYhpH
ytiCbzfgpM5bbKvtSyLKxaIdEE8CY+obNCIXrAtfy7+t/jaMvY7H42yHnfpQgXJe
CAhOXG93wAgOzAkdfQ4YiJksgCM10bGbusApi43MIOxkNQU4C6GPdQAfIYKu8eXz
TIZr6tfnDI0ipF6NOQy2IMqfR+gSUOXG/zLLbfh+vwrVYLO3ISdC2GE60J2X4LjS
GNURtwjIwoHKNMbBakR4
=nGQL
-----END PGP SIGNATURE-----