BIND 8.2.2-P5 problem

[Andrew McNamara]

>> >	Our current theory is that gettimeofday() sometimes returns
>> >	an out of range tv_usec.  We know this true on some BSD
>> >	based machines and have circumstantial evidence that Solaris
>> >	also has this problem.  The BSD machines in question have
>> >	selectable time keeping mechanisms and by telling the kernel
>> >	to use the alternate machanism the problem disappears.
>> 
>> We've just seen this here. Machine is a Sun Sparc t1 (single cpu),
>> running Solaris 8, kernel Generic_108528-08 (the latest).
>> 
>> Have you had any more leads on the Solaris version of this bug? A bug
>> id, or patch id?
>
>	No.  I havn't talked to Sun about this.

Searching on SunSolve suggests this bug has a long history (at least
back to 1998). Sun's "answer" is to perform the gettimeofday() call
again if you get bogus values (I doubt you would want to do this in a
loop - but doing one more gettimeofday() call before tripping the
assertion probably wouldn't hurt).

I'm also slightly suspicious that Solaris has lifted the FreeBSD code
where this bug is also in evidence - there was a comment from a Sun
developer on an unrelated bug in Chorus (for those with access, bug id
4400759) to this effect (it wouldn't be unreasonable to assume code had
been backported from Chorus into Solaris):

    This regression is due to the new IOM time management which is now
    based on FreeBSD 4.1 code with the micro-kernel clock through
    univTimeSet().  FreeBSD doesn't check negative values of tv_sec
    field because it bounds negative time to 1970 in its system clock
    implementation and this is not done in ChorusOS.

BTW, I suspect gettimeofday() isn't a normal system call - it's
significantly faster than other simple system calls (getpid(), time(),
etc), and I have a vague recollection that it uses a magic shared page
mapping that is updated by the kernel to avoid system call overhead. It
could simply be that there is a race between the kernel and userspace
in accessing this page's data.

 ---
Andrew McNamara (System Architect)

connect.com.au Pty Ltd
Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia
Phone: +61 2 9409 2117, Fax: +61 2 9409 2111