Date: Thu, 7 Sep 2006 09:26:22 +0200 From: Stanislaw Halik <sthalik@tehran.lain.pl> To: freebsd-stable@freebsd.org Subject: Re: large system date skew on RELENG_6 changes causes select() failures Message-ID: <20060907072622.GA28784@localhost.localdomain> In-Reply-To: <200609050641.k856fU94094977@drugs.dv.isc.org> References: <20060905060701.GG9421@funkthat.com> <200609050641.k856fU94094977@drugs.dv.isc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 05, 2006, Mark Andrews wrote:
>>> A while ago, by accident, I've changed the system date back to the '98
>>> using date(1). To my astonishment, screen(1) barfed about EINVAL in
>>> select() and died. Programs, including opera (native FreeBSD-6 binary)
>>> kept spinning the CPU until I killed them.
>>> I have no means for debugging it.
>>> Is this somehow expected? If not (i.e. it's a bug), is it known?
>> Probably, they calculated timeout's which magicly became negative, which
>> isn't a valid timeout, and none of the programs are programmed well enough
>> to handle the case and exhibited the behavior that you saw...
> Nope. Just a simple limit in itimerfix.
> int
> itimerfix(struct timeval *tv)
> {
> if (tv->tv_sec < 0 || tv->tv_sec > 100000000 ||
> tv->tv_usec < 0 || tv->tv_usec >= 1000000)
> return (EINVAL);
> if (tv->tv_sec == 0 && tv->tv_usec != 0 && tv->tv_usec < tick)
> tv->tv_usec = tick;
> return (0);
> }
> date -j 9809051630 +%s -> 904977000
> date +%s -> 1157438219
> 1157438219 - 904977000 -> 252461219 which is greater that 100000000
The loop in GNU screen, which invokes select() looks like this:
{
struct timeval t;
t.tv_sec = (long) (msec / 1000);
t.tv_usec = (long) ((msec % 1000) * 1000);
select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &t);
}
There's no time_t substraction at all.
I dare to say that it's a bug.
/me ducks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060907072622.GA28784>