Date: Mon, 16 Sep 2002 16:46:37 +0400 (MSD) From: Maxim Konovalov <maxim@macomnet.ru> To: Ross Finlayson <finlayson@live.com> Cc: Peter Pentchev <roam@ringlet.net>, <freebsd-bugs@FreeBSD.ORG> Subject: Re: named crash (again) Message-ID: <20020916163154.C69014-100000@news1.macomnet.ru> In-Reply-To: <4.3.1.1.20020910124512.00bf6580@laptop-localhost> References: <4.3.1.1.20020910003032.00bf4860@laptop-localhost> <4.3.1.1.20020910003032.00bf4860@laptop-localhost> <4.3.1.1.20020910124512.00bf6580@laptop-localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello,
On 23:51+0400, Sep 10, 2002, Ross Finlayson wrote:
> At 12:38 PM 9/10/02, Peter Pentchev wrote:
> >On Tue, Sep 10, 2002 at 12:32:04AM -0700, Ross Finlayson wrote:
> > > A few days ago, I reported a "named" crash. Tonight, I saw it again:
> >[snip crash info]
> > > Strangely, the error occurred almost exactly 6 days after the previous
> > > occurrence.
> >
> >This means that you may have indeed stumbled upon a genuine BIND bug.
> >Six days is the default time-to-live on a zone NS record; this probably
> >means that BIND crashed last time while either processing the record or
> >building a reply packet for a client, and now, six days later, when the
> >record expired, the resolver tried to look it up again, and crashed in
> >the same way.
> >
> >Could you try to correlate the time of the crash with something either
> >you or your users were doing?
>
> Nothing in particular seemed to be happening at that time. I also looked
> at both my www and mail logs, and nothing was happening there within a few
> seconds of the crash.
>
> > Do you
> >have the ability (disk space, CPU utilization) to turn on BIND's query
> >log and (possibly another six days from now) examine the queries issued
> >around the time of the crash?
>
> Yes, I can probably do this. Please let me know what, in particular, you'd
> like me to put in a
> logging { ... };
> statement in /etc/namedb/named.conf ?
I can confirm periodic named crash on 4.6.2-RELEASE. Here is a debug
log:
Dispatch.File: fd 30, mask 0x1, func 0x805e5b4, uap 0x81484a4
pselect(34, 0xfff000a0, 0x0, 0x0, 0.915570000)
select() returns 1 (err: none)
Dispatch.File: fd 30, mask 0x1, func 0x805e5b4, uap 0x81484a4
pselect(34, 0xfff000a0, 0x0, 0x0, 0.729226000)
select() returns 1 (err: none)
Dispatch.File: fd 30, mask 0x1, func 0x805e5b4, uap 0x81484a4
pselect(34, 0xfff000a0, 0x0, 0x0, 1.-1119342952)
select() returns -1 (err: Invalid argument) <-~ crash
As you see, struct timeval.tv_usec is corrupted but I still do not
know why. ISC eventlib(3) does not expect such corruption and never
checks struct timespec.tv_nsec > 1000000 (except evAddTime(3)).
Ross, do you have
options HZ something
in your kernel config file? Do you run ntpd(8)?
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020916163154.C69014-100000>