GNU bug report logs - #7317
Bug in SLEEP command

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7317 <at> debbugs.gnu.org, Ан, Eric Blake <eblake <at> redhat.com>, дрей Передрий <andi <at> ukr.net>
Subject: bug#7317: Bug in SLEEP command
Date: Wed, 03 Nov 2010 14:21:53 +0000

On 03/11/10 12:41, Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 02/11/10 16:41, Eric Blake wrote:
>>> On 11/02/2010 09:46 AM, Андрей Передрий wrote:
>>>>
>>>> Hello guys!
>>>>
>>>> I found a bug in 'sleep' command.
>>>
>>>> As you can see - 'sleep' was terminated by himself after 24 days, 20 hours, 26 minutes and 33 seconds.
>>>> 24*24*3600 + 20*3600 + 26*60 + 33 = 2073600 + 72000 + 1560 + 33 = 2147193 seconds
>>>> It seems like overflow.
>>>> coreutils 6.10-6
>>>> Debian 5.0.6
>>>
>>> Is your system 32-bit or 64-bit?  It makes a difference in determining
>>> whether there is a bug in the OS sleep primitives (for example, we know
>>> that 64-bit Linux has a bug where nanosleep with an extremely large
>>> value will cause the kernel to overflow and sleep for the wrong amount
>>> of time, but coreutils has workarounds in place for that).
>>
>> I had a quick look at the gnulib replacement which
>> seems to assume 49 days is the worst case,
>> whereas we now need to use 24 days?
> 
> Sounds reasonable.  It'd be good to document which kernel(s) are affected.
> Have you reproduced it? (i.e., in a VM, changing the date, if that is sufficient)
> 

The only mention in the gnulib nanosleep docs about linux is:

"This function mishandles large arguments when interrupted by
a signal on some platforms: Linux 64-bit, Solaris 64-bit."

This may or may not be related to:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1711ef38

So the OPs case seems different I think in that he's using 32 bit
on RHEL & Centos 4.6 & 4.8 with 2.6.9-89.0.23.ELsmp

I'm not sure if setting the date is enough.
I tried on my 2.6.30 32bit laptop with no issue.
Андрей did you set the date, or did you really wait 24 days :)

This reminds me of a more general idea I noticed recently:
http://rwmj.wordpress.com/2010/10/14/half-baked-ideas-accelerated-testing-for-vms/

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.