Re: large system date skew on RELENG_6 changes causes select() failures

2006-09-07 Thread Stanislaw Halik
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  1 ||
 tv-tv_usec  0 || tv-tv_usec = 100)
 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 1

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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: large system date skew on RELENG_6 changes causes select() failures

2006-09-07 Thread Mark Andrews

 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  1 ||
  tv-tv_usec  0 || tv-tv_usec = 100)
  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 1
 
 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
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]

man select gives:

 [EINVAL]   The specified time limit is invalid.  One of its com-
ponents is negative or too large.

too large is  1 seconds which can be found by
inspecting the kernel source.  In particular itimerfix().

A simple fix for screen would be to put a upper bound on
tv_sec which is = 1.

Mark
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [EMAIL PROTECTED]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: large system date skew on RELENG_6 changes causes select() failures

2006-09-05 Thread John-Mark Gurney
Stanislaw Halik wrote this message on Tue, Sep 05, 2006 at 06:51 +0200:
 Hello,
 
 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...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: large system date skew on RELENG_6 changes causes select() failures

2006-09-05 Thread Mark Andrews

 Stanislaw Halik wrote this message on Tue, Sep 05, 2006 at 06:51 +0200:
  Hello,
  
  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  1 ||
tv-tv_usec  0 || tv-tv_usec = 100)
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 1

 
 -- 
   John-Mark GurneyVoice: +1 415 225 5579
 
  All that I will do, has been done, All that I have, has not.
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [EMAIL PROTECTED]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


large system date skew on RELENG_6 changes causes select() failures

2006-09-04 Thread Stanislaw Halik
Hello,

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?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]