Time bug is kernel bug, not MLton

[Matthew Fluet]

> Yay:  the Time bug is definitely a kernel bug bug, not a MLton bug.  The hint
> was they mail from Matthew on the .99.  I have C code that will cause the bug
> to show up.  It only seems to happen on an SMP machine, but if I run 3 copies
> of the program, one usually gets the axe within a few minutes.

Only seems to happen on an SMP machine, or only can happen on an SMP
machine?  I've been producing the bug with a self-compile on a single
processor machine.  Also, using your program on the same machine, I've
gotten these:

Binfo for self sys, old = 92 seconds + 990000, new = 92 seconds + 0
Binfo for self sys, old = 86 seconds + 990000, new = 86 seconds + 0

> The thing that is confusing me is that one time it died as follows:
>
>     syzygy> htime zulu
>     unhandled exception Time
>     Command exited with non-zero status 1
>
>     real    0:51.70
>     user    23.91
>     sys     11.00
>
> The  system  time  is 11.00, so I'm sure it was that which killed it, but who
> raised the Time exception in an unhandled context?  The  whole  way  I  wrote
> showTime  was  to  make  this  impossible  (and  to  make sure I got the full
> accuracy of the time without any floating  point  strangeness).   I  must  be
> missing  something easy here, but I have looked at it for a while and have no
> idea.  Any notions?

You could conceivably get a Time exception in the execution of
MLton.Rusage.rusage ().  There are calls to Time.fromSeconds and
Time.fromMicroseconds that raise Time when called on a negative argument.
But, from your descriptions, it doesn't seem like the kernel shouldn't
ever return a negative number, even in places where these funny roll-overs
happen.