GNU bug report logs -
#7317
Bug in SLEEP command
Previous Next
Reported by: Андрей Передрий <andi <at> ukr.net>
Date: Tue, 2 Nov 2010 15:46:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7317 in the body.
You can then email your comments to 7317 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Tue, 02 Nov 2010 15:46:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Андрей Передрий <andi <at> ukr.net>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Tue, 02 Nov 2010 15:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello guys!
I found a bug in 'sleep' command.
Please see below:
# date
Tue Oct 5 14:12:11 EEST 2010
[root <at> gate ~]# sleep 36500d ; date
Sat Oct 30 10:38:44 EEST 2010
[root <at> gate ~]#
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
--
A.P.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Tue, 02 Nov 2010 16:38:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 7317 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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).
Also, consider upgrading; the latest stable coreutils release is 8.6,
and there have been some gnulib fixes in the meantime to improve the
robustness of the sleep workarounds in use by coreutils.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Tue, 02 Nov 2010 16:56:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 7317 <at> debbugs.gnu.org (full text, mbox):
On 02/11/10 15:46, Андрей Передрий wrote:
>
> Hello guys!
>
> I found a bug in 'sleep' command.
> Please see below:
>
> # date
> Tue Oct 5 14:12:11 EEST 2010
> [root <at> gate ~]# sleep 36500d ; date
> Sat Oct 30 10:38:44 EEST 2010
> [root <at> gate ~]#
>
> 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
eek!
That's lenny right, with kernel 2.6.32 or so.
POSIX says that we should support 2147483647 seconds at least.
We could make multiple calls to xnanosleep if the param is
greater than that, but do we really need to support > 68 years.
Currently we silently truncate to this limit.
Anyway could you send the output of: strace sleep 36500d
On 64 bit lenny here I get: nanosleep({3153600000, 0},
On 32 bit Fedora 11 I get: nanosleep({2147483647, 999999999}
If you get a large value being passed down,
then it suggests an issue with glibc/kernel?
cheers,
Pádraig.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Tue, 02 Nov 2010 17:27:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 7317 <at> debbugs.gnu.org (full text, mbox):
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?
cheers,
Pádraig.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Tue, 02 Nov 2010 17:36:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 7317 <at> debbugs.gnu.org (full text, mbox):
> >
> > 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).
>
> Also, consider upgrading; the latest stable coreutils release is 8.6,
> and there have been some gnulib fixes in the meantime to improve the
> robustness of the sleep workarounds in use by coreutils.
>
I am sorry!
Correct platform is:
RHEL & Centos 4.6 & 4.8
2.6.9-89.0.23.ELsmp
strace sleep 36500d
execve("/bin/sleep", ["sleep", "36500d"], [/* 20 vars */]) = 0
uname({sys="Linux", node="gate.shipregistr.kiev.ua", ...}) = 0
brk(0) = 0x9541000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=20328, ...}) = 0
old_mmap(NULL, 20328, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f56000
close(3) = 0
open("/lib/tls/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0003\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=212236, ...}) = 0
old_mmap(NULL, 139424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x54d000
old_mmap(0x56e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x20000) = 0x56e000
close(3) = 0
open("/lib/tls/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320 \0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=48788, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f55000
old_mmap(NULL, 81656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x28b000
old_mmap(0x293000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x293000
old_mmap(0x295000, 40696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x295000
close(3) = 0
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200O\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1544948, ...}) = 0
old_mmap(NULL, 1244380, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x111000
old_mmap(0x23b000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x129000) = 0x23b000
old_mmap(0x23f000, 7388, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x23f000
close(3) = 0
open("/lib/tls/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0PH\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=105912, ...}) = 0
old_mmap(NULL, 70108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x650000
old_mmap(0x65e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x65e000
old_mmap(0x660000, 4572, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x660000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f54000
mprotect(0x65e000, 4096, PROT_READ) = 0
mprotect(0x23b000, 8192, PROT_READ) = 0
mprotect(0x293000, 4096, PROT_READ) = 0
mprotect(0x56e000, 4096, PROT_READ) = 0
mprotect(0xfbe000, 4096, PROT_READ) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f546c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7f56000, 20328) = 0
set_tid_address(0xb7f54708) = 19936
rt_sigaction(SIGRTMIN, {0x654380, [], SA_RESTORER|SA_SIGINFO, 0x65bc90}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x6543f0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x65bc90}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfe5e27c, 35, (nil), 0}) = 0
brk(0) = 0x9541000
brk(0x9562000) = 0x9562000
clock_gettime(CLOCK_REALTIME, {1288719488, 927427000}) = 0
nanosleep({2147483647, 999999999},
--
A.P.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Tue, 02 Nov 2010 17:38:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 7317 <at> debbugs.gnu.org (full text, mbox):
> On 02/11/10 15:46, Андрей Передрий wrote:
> >
> > Hello guys!
> >
> > I found a bug in 'sleep' command.
> > Please see below:
> >
> > # date
> > Tue Oct 5 14:12:11 EEST 2010
> > [root <at> gate ~]# sleep 36500d ; date
> > Sat Oct 30 10:38:44 EEST 2010
> > [root <at> gate ~]#
> >
> > 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
>
> eek!
> That's lenny right, with kernel 2.6.32 or so.
>
> POSIX says that we should support 2147483647 seconds at least.
> We could make multiple calls to xnanosleep if the param is
> greater than that, but do we really need to support > 68 years.
> Currently we silently truncate to this limit.
>
> Anyway could you send the output of: strace sleep 36500d
>
> On 64 bit lenny here I get: nanosleep({3153600000, 0},
> On 32 bit Fedora 11 I get: nanosleep({2147483647, 999999999}
>
> If you get a large value being passed down,
> then it suggests an issue with glibc/kernel?
>
> cheers,
> P?draig.
uname -a
Linux ************* 2.6.9-89.0.23.ELsmp #1 SMP Wed Mar 17 06:55:21 EDT 2010 i686 athlon i386 GNU/Linux
cat /etc/redhat-release
CentOS release 4.8 (Final)
--
A.P.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Wed, 03 Nov 2010 12:38:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 7317 <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Wed, 03 Nov 2010 14:18:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 7317 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Wed, 03 Nov 2010 15:01:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 7317 <at> debbugs.gnu.org (full text, mbox):
> 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 :)
I really wait 24 days :)
I used command "sleep 36500d" in my script for infinite loop organization.
I tested this 2 times in RHEL4.6 in real (non virtualized) environment.
And 1 time in Centos48 (in real env)
So I found this bug firstly 49 days ago :)
--
A.P.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7317; Package
coreutils.
(Wed, 03 Nov 2010 18:01:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 7317 <at> debbugs.gnu.org (full text, mbox):
On 11/03/10 07:21, Pádraig Brady wrote:
>>> 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?
It's worse than that, no? We need a test in m4/nanosleep.m4
that detects the bug. If 'configure' can't reliably detect the bug,
it'll have to assume that it's present, and always replace nanosleep.
Perhaps we can limit this assumption to all 32-bit Linux platforms,
but still, it'd be nicer if we could reliably detect this bug
(and we don't want "configure" to run for 24.4 days to find out!).
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>:
You have taken responsibility.
(Fri, 12 Nov 2010 14:30:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Андрей Передрий <andi <at> ukr.net>:
bug acknowledged by developer.
(Fri, 12 Nov 2010 14:30:03 GMT)
Full text and
rfc822 format available.
Message #37 received at 7317-done <at> debbugs.gnu.org (full text, mbox):
On 02/11/10 17:30, 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?
Fixed with:
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2f2b6680
cheers,
Pádraig.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 11 Dec 2010 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 250 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.