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>