From owner-freebsd-stable@FreeBSD.ORG Tue Sep 5 06:41:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC54016A4EE for ; Tue, 5 Sep 2006 06:41:37 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9749F43D5C for ; Tue, 5 Sep 2006 06:41:34 +0000 (GMT) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id CAC7AE601F for ; Tue, 5 Sep 2006 06:41:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k856fU94094977 for ; Tue, 5 Sep 2006 16:41:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200609050641.k856fU94094977@drugs.dv.isc.org> To: freebsd-stable@freebsd.org From: Mark Andrews Mail-Followup-To: freebsd-stable@freebsd.org In-reply-to: Your message of "Mon, 04 Sep 2006 23:07:01 MST." <20060905060701.GG9421@funkthat.com> Date: Tue, 05 Sep 2006 16:41:30 +1000 Sender: Mark_Andrews@isc.org Subject: Re: large system date skew on RELENG_6 changes causes select() failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2006 06:41:38 -0000 > Stanislaw Halik wrote this message on Tue, Sep 05, 2006 at 06:51 +0200: > > Hello, > > > > 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 > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training@isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org