NetBSD Problem Report #37726

From martin@duskware.de  Wed Jan  9 12:59:58 2008
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id C4A1263BD87
	for <gnats-bugs@gnats.netbsd.org>; Wed,  9 Jan 2008 12:59:58 +0000 (UTC)
Message-Id: <20080109063028.836BA63BD87@narn.NetBSD.org>
Date: Wed,  9 Jan 2008 06:30:28 +0000 (UTC)
From: nbsd1@y2008.pianocast.net
Reply-To: nbsd1@y2008.pianocast.net
To: netbsd-bugs-owner@NetBSD.org
Subject: request documentation of 2147 second limit on adjtime(2)
X-Send-Pr-Version: www-1.0

>Number:         37726
>Category:       kern
>Synopsis:       32-bit overflow in adjtime(2)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 09 13:00:00 +0000 2008
>Last-Modified:  Sat Jan 05 22:55:02 +0000 2013
>Originator:     Dave B
>Release:        NetBSD 3.1_STABLE / i386
>Organization:
>Environment:
Many versions / platforms are probably affected.  A quick Google
search suggested the problem existed in, e.g., FreeBSD in 1999, as
well.
>Description:
If I pass a value of 2147 (long) in tv_sec, adjtime()
works fine--and the clock gradually advances; however, if
I pass a value of 2148 or greater, it returns success, yet
the clock starts to slow down--and a subsequent call
adjtime() returns erroneous, negative values in
olddelta.tv_sec and olddelta.tv_usec.

>How-To-Repeat:
/* A code snippet which may help. ** adjtime.c ** */

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>

int
adjtime( const struct timeval *delta, struct timeval *olddelta );

main( int argc, char *argv[] )
{
  int stat ;
  long l_sec, l_usec ;
  struct timeval delta, olddelta ;

  if ( argc != 2 ) {
    fprintf( stderr, "Usage: %s <(long) seconds to step>\n\n",
      argv[0] );
    exit(1);
  }

  l_sec = atol( argv[1] );

  delta.tv_sec = l_sec ;
  delta.tv_usec = 0L ;

  stat = adjtime( &delta, &olddelta );
  if (stat != 0) {
    perror( "main()/adjtime()" );
  }

  printf( "Old: %ld.%ldsec\n", olddelta.tv_sec, olddelta.tv_usec );
}
>Fix:
Add user-friendly explanation (by someone with the needed language
skills...) of the limitation described above to the adjtime(2) man
page (and maybe to rdate(8)? Although rdate(8) does refer to adjtime(2)
already; so, less necessary).

>Release-Note:

>Audit-Trail:

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/37726: request documentation of 2147 second limit on
 adjtime(2)
Date: Thu, 3 Jan 2013 21:55:25 +0000

 This is a bug (there's a 32-bit microseconds value in there that's
 overflowing and becoming negative), assuming it still happens at all
 these days. I'm going to update the Synopsis: and Class: and bump the
 priority.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Dave B <nbsd1@y2013.pianocast.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/37726: request documentation of 2147 second limit on
 adjtime(2)
Date: Sat, 5 Jan 2013 16:31:47 -0500

 > From: David Holland <dholland-bugs@netbsd.org>
 > Subject: Re: kern/37726: request documentation of 2147 second limit on
 >  adjtime(2)
 > 
 >  This is a bug (there's a 32-bit microseconds value in there that's
 >  overflowing and becoming negative), assuming it still happens at all
 >  these days. I'm going to update the Synopsis: and Class: and bump the
 >  priority.

   Thanks, David.  Good to see your name on the case.

   True: I don't use adjtime very often these days and I don't have
 a use-case in mind in which doing a greater-than-2147-second
 adjustment is of key importance... hence my initial low prio.

   All the same, from a correctness standpoint--and even if for no
 other reason than intellectual curiosity on how well slewing the
 clock would work over the course of, say, an entire week--a bugfix
 sounds great to me.

 -Dave B.

>Unformatted:

Home	PR Database Search