From j@uriah.heep.sax.de  Sun Aug 10 01:51:39 1997
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA11107
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 10 Aug 1997 01:51:38 -0700 (PDT)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA05434 for FreeBSD-gnats-submit@freebsd.org; Sun, 10 Aug 1997 10:51:33 +0200
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.7/8.8.5) id KAA01086;
	Sun, 10 Aug 1997 10:26:43 +0200 (MET DST)
Message-Id: <199708100826.KAA01086@uriah.heep.sax.de>
Date: Sun, 10 Aug 1997 10:26:43 +0200 (MET DST)
From: J Wunsch <j@uriah.heep.sax.de>
Reply-To: j@uriah.heep.sax.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: sleep(3) broken for large values
X-Send-Pr-Version: 3.2

>Number:         4259
>Category:       bin
>Synopsis:       sleep(3) broken for large values
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 10 02:00:02 PDT 1997
>Closed-Date:    Sun Aug 10 14:16:20 MEST 1997
>Last-Modified:  Sun Aug 10 06:10:02 PDT 1997
>Originator:     J Wunsch
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
>Environment:

-current as of yesterday.

>Description:

sleep(3) is now broken for arguments > 100000000 seconds (threshold
found empirically); it returns immediately in this case.  Among
others, this breaks perl(1)'s `sleep' instruction when being used
without any argument (since this will call sleep(0xffffffff)).

>How-To-Repeat:

perl -e sleep

This is not supposed to finish in the forseeable future, but
immediately returns you to the command prompt.

>Fix:
	
Not yet known.


>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, j@uriah.heep.sax.de
Cc:  Subject: Re: bin/4259: sleep(3) broken for large values
Date: Sun, 10 Aug 1997 21:22:43 +1000

 >sleep(3) is now broken for arguments > 100000000 seconds (threshold
 >found empirically); it returns immediately in this case.  Among
 
 It's always been broken like that.  Anything involving itimers is
 restricted to an interval of 10^8 seconds (see itimerfix()).  The problem
 is more serious for sleep() than for setitimer() because sleep()
 "can't fail".  Perhaps the error handling is sloppier than before -
 errors for signanosleep(2) are not checked for, and the remaining time
 is not set for EINVAL errors (I think it should only be set for EINTR
 errors as in Linux - setting it in other cases is a waste of time and
 can't be relied on by portable applications).
 
 Restricting the interval to 10^8 seconds avoids overflow problems (until
 10^ seconds = about 3 years before time_t overflows :-).  tv_usec's are
 signed longs in `struct timeval' and time_t's (which happen to be signed
 longs) in `struct timespec', so UINT_MAX is not representable on systems
 with normal 32-bit ints and longs.  nanosleep(2) should split up the
 interval into pieces <= 10^8 seconds long and sleep(3) should split up
 the interval into pieces <= TIME_T_MAX long if it is implemented using
 nanosleep().
 
 Bruce
State-Changed-From-To: open->closed 
State-Changed-By: joerg 
State-Changed-When: Sun Aug 10 14:16:20 MEST 1997 
State-Changed-Why:  
Workaround implemented in rev 1.13 of libc/gen/sleep.c. 

From: j@uriah.heep.sax.de (J Wunsch)
To: bde@zeta.org.au (Bruce Evans)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/4259: sleep(3) broken for large values
Date: Sun, 10 Aug 1997 14:26:40 +0200

 As Bruce Evans wrote:
 
 > >sleep(3) is now broken for arguments > 100000000 seconds (threshold
 > >found empirically); it returns immediately in this case.  Among
 > 
 > It's always been broken like that.
 
 Apparently not.  It used to work.  I've only noticed the problem since
 one of my perl child processes that's running as a daemon like
 
 	for (;;)
 		sleep;	# wait until we are being killed
 
 suddenly started to eat up one CPU (out of a total of one :).
 
 >   nanosleep(2) should split up the
 > interval into pieces <= 10^8 seconds long and sleep(3) should split up
 > the interval into pieces <= TIME_T_MAX long if it is implemented using
 > nanosleep().
 
 The quick&dirty fix was to limit sleep(3)'s argument to 100000000
 seconds.
 
 At least, this constant needs to be explained in documentation
 (itimerfix(9), nanosleep(2), etc.), and to be visible in a public
 header file, as opposed to be `implicit knowledge' you can only gain
 by reading kernel sources.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)
>Unformatted:
