From owner-freebsd-stable@FreeBSD.ORG Thu Sep 7 13:55:35 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 DB0EA16A4DA for ; Thu, 7 Sep 2006 13:55:35 +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 D68E843D5E for ; Thu, 7 Sep 2006 13:55:31 +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 C8C2DE601F for ; Thu, 7 Sep 2006 13:55:30 +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 k87DtQNW047776 for ; Thu, 7 Sep 2006 23:55:27 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200609071355.k87DtQNW047776@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 "Thu, 07 Sep 2006 09:26:22 +0200." <20060907072622.GA28784@localhost.localdomain> Date: Thu, 07 Sep 2006 23:55:26 +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: Thu, 07 Sep 2006 13:55:35 -0000 > 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 > _______________________________________________ > 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" "man select" gives: [EINVAL] The specified time limit is invalid. One of its com- ponents is negative or too large. "too large" is > 100000000 seconds which can be found by inspecting the kernel source. In particular itimerfix(). A simple fix for screen would be to put a upper bound on tv_sec which is <= 100000000. Mark -- 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