>Number:         2585
>Category:       kern
>Synopsis:       time accumulated in subprocesses often is bad
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul  1 08:35:02 1996
>Last-Modified:
>Originator:     Matthias Pfaller
>Organization:
	marco GmbH, Dachau, Germany
>Release:        1.2_ALPHA
>Environment:
	<machine, os, target, libraries (multiple lines)>
System: NetBSD klondike 1.2_ALPHA NetBSD 1.2_ALPHA (KLONDIKE) #9: Sun Jun 23 01:24:08 MET DST 1996 leo@klondike:/usr/src/sys/arch/pc532/compile/KLONDIKE pc532


>Description:
	When doing a "ps -S" I often see processes that have accumulated
	more runtime then the system's uptime.
	The reason for this is that in sys/kern/kern_resource.c:calcru()
	the variable usec is declared as u_long.
	The usec value is computed with:

		usec = p->p_rtime.tv_usec;
		if (p == curproc) {
			/*
			 * Adjust for the current time slice.  This is actually fairly
			 * important since the error here is on the order of a time
			 * quantum, which is much greater than the sampling error.
			 */
			microtime(&tv);
			sec += tv.tv_sec - runtime.tv_sec;
			usec += tv.tv_usec - runtime.tv_usec;
		}
		u = (u_quad_t) sec * 1000000 + usec;

	As one can see it is possible for usec to get <0 when p == curproc.
	In this case the computation of u will typically be about 4300
	seconds to high.
>How-To-Repeat:
	Just do a "ps -S". I'm quite sure you will see this as well.
>Fix:
--- kern_resource.c.ORIG	Sat Jun 15 13:22:06 1996
+++ kern_resource.c	Mon Jul  1 00:11:07 1996
@@ -333,7 +333,8 @@
 	register struct timeval *ip;
 {
 	register u_quad_t u, st, ut, it, tot;
-	register u_long sec, usec;
+	register u_long sec;
+	register long usec;
 	register int s;
 	struct timeval tv;
 
>Audit-Trail:
>Unformatted: