Re: [9fans] dns

[erik quanstrom <quanstro@quanstro.net>]

On Tue Aug 21 07:31:55 EDT 2012, cinap_lenrek@gmx.de wrote:
> nothing wrong with diffing the changes and see if theres a clue, but
> to solve this one really needs to find the underlying cause no matter
> what. changes can just hide bugs or make them more or less likely to
> appear. can anyone provide at least a stacktrace or process snapshot
> of the crashed dns processes? from that you try to build a theory of
> what might be going wrong by thinking really really hard... (the
> thinking should be directly proportional to the time it takes to
> reproduce the bug) and then you work on how to prove that theory.
> just changing stuff without knowing what exactly was the problem with
> the old code is sometimes tempting, but wrong and dangerous.

very good point.  in the past, much of the trouble has been that the
rr records get smashed and you crash much later on.  this makes debugging
from a crash frustrating.

but as it happily turns out, i keep all the snaps of all my broken dns processes.
i've had ~35 since january, when i last looked at dns.  as it turns out
all of the crashes were due to an off-by-one in dnresolv:/^serveraddrs
the final loop in the function should be limited by Maxdest-1, since
Maxdest is an index not a count.

with this fixed, it will be interesting to see if we see better behavior
or not.  my big concern right now is occassionally corrupted results we
see.  the crashes and whatnot are relatively easy to clean up after.

if anyone else is interested in my compendium of dnssnaps, i'd be happy
to send them along.  there's only a gb of them!  :-).

- erik