From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: arisawa <arisawa@ar.aichi-u.ac.jp>
In-Reply-To: <ba9d398c37fc96db023fd66fe34dacf4@rei2.9hal>
Date: Tue, 21 Aug 2012 21:37:08 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <067087A9-70B3-4F1C-AA7A-CF1188FC9B2A@ar.aichi-u.ac.jp>
References: <ba9d398c37fc96db023fd66fe34dacf4@rei2.9hal>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] dns
Topicbox-Message-UUID: ad6fd488-ead7-11e9-9d60-3106f5b1d025

Hello,

Files in /sys/src/cmd/ndb are not be changed since this Mar 31.
However dns in /n/sources/plan9/386/bin/ndb have changed two or three =
times since that day.
Probably the difference comes from others (library?).

hera% pwd
/sys/src/cmd/ndb
hera% ls -lt
--rw-rw-r-- M 21422 sys sys 34365 Mar 31 05:41 cs.c
--rw-rw-r-- M 21422 sys sys 40329 Mar 29 08:07 dn.c
--rw-rw-r-- M 21422 sys sys 20706 Mar 29 08:01 dns.c
--rw-rw-r-- M 21422 sys sys  6916 Oct 14  2011 dnudpserver.c
--rw-rw-r-- M 21422 sys sys 39487 Oct 14  2011 dnresolve.c
--rw-rw-r-- M 21422 sys sys 12571 Oct 14  2011 convM2DNS.c

hera% ls -lt /n/sources/plan9/sys/src/cmd/ndb
--rw-rw-r-- M 21436 glenda sys 34365 Mar 31 05:41 =
/n/sources/plan9/sys/src/cmd/ndb/cs.c
--rw-rw-r-- M 21436 glenda sys 40329 Mar 29 08:07 =
/n/sources/plan9/sys/src/cmd/ndb/dn.c
--rw-rw-r-- M 21436 glenda sys 20706 Mar 29 08:01 =
/n/sources/plan9/sys/src/cmd/ndb/dns.c
--rw-rw-r-- M 21436 glenda sys  6916 Oct 14  2011 =
/n/sources/plan9/sys/src/cmd/ndb/dnudpserver.c
--rw-rw-r-- M 21436 glenda sys 39487 Oct 14  2011 =
/n/sources/plan9/sys/src/cmd/ndb/dnresolve.c
--rw-rw-r-- M 21436 glenda sys 12571 Oct 14  2011 =
/n/sources/plan9/sys/src/cmd/ndb/convM2DNS.c

>the old code is sometimes tempting, but wrong and dangerous.
I agree. And I wonder why dns runs as bootes (sever owner).

Kenji Arisawa

On 2012/08/21, at 20:27, 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.
>=20
> --
> cinap
>=20