From owner-freebsd-stable@FreeBSD.ORG Thu Sep 7 07:27: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 4E7C816A4DA for ; Thu, 7 Sep 2006 07:27:37 +0000 (UTC) (envelope-from sthalik@tehran.lain.pl) Received: from mail.in5.pl (rollercoaster.insane.pl [213.251.173.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8F7143D45 for ; Thu, 7 Sep 2006 07:27:35 +0000 (GMT) (envelope-from sthalik@tehran.lain.pl) Received: from c182-250.icpnet.pl ([85.221.182.250] helo=enkidu.local) by mail.in5.pl with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (envelope-from ) id 1GLEIQ-0006QP-AR for freebsd-stable@freebsd.org; Thu, 07 Sep 2006 09:27:34 +0200 Received: from sthalik by enkidu.local with local (Exim 4.63) (envelope-from ) id 1GLEHG-0007UU-MO for freebsd-stable@freebsd.org; Thu, 07 Sep 2006 09:26:22 +0200 Date: Thu, 7 Sep 2006 09:26:22 +0200 From: Stanislaw Halik To: freebsd-stable@freebsd.org Message-ID: <20060907072622.GA28784@localhost.localdomain> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060905060701.GG9421@funkthat.com> <200609050641.k856fU94094977@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609050641.k856fU94094977@drugs.dv.isc.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-User: sthalik 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 07:27:37 -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