On Tue, Sep 05, 2006, Mark Andrews wrote:
>>> A while ago, by accident, I've changed the system date back to the '98
>>> using date(1). To my astonishment, screen(1) barfed about EINVAL in
>>> select() and died. Programs, including opera (native FreeBSD-6 binary)
>>> kept spinning the CPU until I killed them.
>>> I have no means for debugging it.
>>> Is this somehow expected? If not (i.e. it's a bug), is it known?
>> Probably, they calculated timeout's which magicly became negative, which
>> isn't a valid timeout, and none of the programs are programmed well enough
>> to handle the case and exhibited the behavior that you saw...
> Nope. Just a simple limit in itimerfix.
> int
> itimerfix(struct timeval *tv)
> {
> if (tv->tv_sec < 0 || tv->tv_sec > 100000000 ||
> tv->tv_usec < 0 || tv->tv_usec >= 1000000)
> return (EINVAL);
> if (tv->tv_sec == 0 && tv->tv_usec != 0 && tv->tv_usec < tick)
> tv->tv_usec = tick;
> return (0);
> }
> date -j 9809051630 +%s -> 904977000
> date +%s -> 1157438219
> 1157438219 - 904977000 -> 252461219 which is greater that 100000000
The loop in GNU screen, which invokes select() looks like this:
{
struct timeval t;
t.tv_sec = (long) (msec / 1000);
t.tv_usec = (long) ((msec % 1000) * 1000);
select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &t);
}
There's no time_t substraction at all.
I dare to say that it's a bug.
/me ducks
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
