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.
