[comp.sys.dec.micro] weird time bug

tlutz%ctios1%ctiov2@ctio (09/23/88)

Received: from ctios1.ctio.edu by ctiov2.ctio.edu with INTERNET ;
          Thu, 22 Sep 88 14:53:53 AST
Received: by ctios1.ctio.edu (3.2/JBH.3)
	id AA04441; Thu, 22 Sep 88 14:52:10 AST
Date: Thu, 22 Sep 88 14:52:10 AST
From: tlutz@ctios1 (t.lutz)
Message-Id: <8809221852.AA04441@ctios1.ctio.edu>
To: info-dec-micro@andrew.cmu.edu, tlutz
Subject: Re: weird time bug
 
>From: m0p@k.cc.purdue.edu  (S. Kulikowski)
 
>  need debugging help. boy, this is a wierd one and i am at wits end.
 
>  i  have  written  some  realtime  programs which consult the MSDOS clock
>frequently and record performance data in files.  running on a DEC rainbow
>with MSDOS v.  2.11.1.  the program with  the  bug  is  written  in  Turbo
>Pascal and i have compiled it with TP3 and TP4 and the bug survives both.
 
>  last  year we ran 70+ kids through the program in a research project and
>each kid produced 8 files each with data in them.  some 40+  megabytes  in
>total data.  upon analysis, 10 files were found to be truncated.
 
>  the  only  thing they have in common was that they had been operating at
>9:06 AM when no further data entered the files beyond the time 9:06:09 AM.
>research notes and subsequent testing show that the program  IO  continues
>on the monitor as usual but NO FURTHER DATA ENTERS THE FILE AFTER 9:06:09.
>this happens in any location (3 different schools and in our lab at the
>university).  all other times (so far) appear to be rock solid.
 
You would probably have mentioned it if you had already noticed that
9h 06m 09s is 32769 seconds after midnight. Since 32768 is 2^15, it would
appear that somewhere you are putting the number of seconds which have elapsed
since midnight into a 16-bit signed register or signed storage location. The
sign uses up one of the bits, and when you try to add one second too many you
either change the sign (what is negative time on a clock?) or reset to zero or
something. What actually happens depends on the interaction between your clock
and your software. 
 
If your program is using seconds to keep track of time, you may need
to modify it. For instance, suppose a student starts at 9:00:00 a.m. If you
are doing something like trying to keep track of how long the student is
logged in to your program, you might convert 9 hours to seconds and then add
one to it each time the clock ticks. At exactly 9:06:09 you will overflow and
who knows what will happen? To get around this, save the hours, minutes and
seconds separately. Its a nuisance, but it works.
 
In any event, the fact that your program hits a problem at exactly 2^15
seconds after midnight is unlikely to be a coincidence.
 
Tom Lutz
tlutz@noao.edu