[Unbound-users] Potential Bug

[W.C.A. Wijngaards]

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

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 :-) )

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

iQIcBAEBAgAGBQJOCz3uAAoJEJ9vHC1+BF+NkO4P/RbucMz6np8Y2NDEasz2tvWM
0jFnaAciuPhxZMEkj7Mewwor8PvYOYzHLYFeXGFN50LhymUhkK+OjD99gTqL1AJY
+s/92K27uUwzVMknwprFEQfcPiHQqqKVatisvIYUy7+ajSC8Gpdcy2Xi/SXBpzTR
kcBwNlUJtn4k+HMOGqHJPVbIYiFZ0Owg2R5JeI+8Sl39VAJFku5i0XaHrY6fRGTW
3HgodWUO+x8sCophVkLRSfBtzwY71BsHKoiKGO51ags67ca9y3poTz5wsmyMdsyC
Q6RsotprIuY8Cpp287odpa4KPrxH/YA5SuwAI4eHmoDmOxjo/2Fu2dBjNUBfGRCd
gtrmXhhe5P79NvGAhVaLOR2NxKAtrS5KAV6dFZmNpDQzAE/iZJP1lQVyc9D+6kcC
JUEu/OD/iodh6U+bSNsTup0oAwgrOCAOyfzBN/CGXmHl2F+MlojbITQMnIcFG0b2
4zpBA4vWuD7B6ViNm7TFVVS/Trw18fysz1T3Mkmlj390mLvGoCZQ1jYDyI/pxUv+
9jolMtKQYVlB5I75VlCkDK/S5EbHu3k0vMDvqIoURqFNgBfgxGMOvo1TmxU0TdfM
5gUbzTCJvjReOBcr4Vr/ZHJZerFPKBrtb2EswEJXS9OImZWlgMHsZwAJShCd3kZS
XM7SaT7ZTgkVwxuQyxkl
=SApS
-----END PGP SIGNATURE-----