Bug 78957 - time counter per process stops (syscall: getrusage)
Summary: time counter per process stops (syscall: getrusage)
Status: Closed DUPLICATE of bug 76972
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-17 20:50 UTC by Jakub Kruszona-Zawadzki
Modified: 2018-04-22 23:30 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Kruszona-Zawadzki 2005-03-17 20:50:02 UTC
When a process is running for a long time (several days) time counter per process stops on value: 
ru_utime.tv_sec:305221
ru_utime.tv_usec:322735

Fix: 

No idea - may be something is wrongly calculated in kernel ???
How-To-Repeat: write something like this:

void main() {
struct rusage rus;
while (1) {
.. do something that uses the processor for a few minutes - loop with some calculations ...
getrusage(RUSAGE_SELF,&rus);
printf("ru_utime.tv_sec:%ld | ru_utime.tv_usec:%ld",rus.ru_utime.tv_sec,rus.ru_utime.tv_usec);
}
}

compile and run then wait about 305000s (about 3.5 days)
Comment 1 Bruce Evans 2005-03-18 09:06:15 UTC
On Thu, 17 Mar 2005, Jakub Kruszona-Zawadzki wrote:

>> Description:
> When a process is running for a long time (several days) time counter per process stops on value:
> ru_utime.tv_sec:305221
> ru_utime.tv_usec:322735

This may be the same bug as in PR 76972.  Overflow occurs at about
48592008 ticks = 379625 seconds = 105 hours for a a process that consumes
100% of the CPU if the statclock frequency is 128 Hz (which is the default
and not easy to change).  There is another overflow bug at 2^32 ticks = 388
days.  This one is harder to fix.  See PR 76972 for details and a fix for
the first overflow bug.

37965 seconds is a little larger than 305221 seconds.  The difference might
be due to the other 70000+ seconds being in ru_stime.

The behaviour when overflow occurs is undefined, but stopping on a value
is quite likely to occur due to the algorithm for updating ru_*time.
Integer overflow tends to cause counters to reset to 0 (or INT_MIN),
but the kernel enforces monotonicity of the usage times, so they will
stick instead of going backwards to 0.

Bruce
Comment 2 Bruce Evans 2005-03-18 09:06:15 UTC
On Thu, 17 Mar 2005, Jakub Kruszona-Zawadzki wrote:

>> Description:
> When a process is running for a long time (several days) time counter per process stops on value:
> ru_utime.tv_sec:305221
> ru_utime.tv_usec:322735

This may be the same bug as in PR 76972.  Overflow occurs at about
48592008 ticks = 379625 seconds = 105 hours for a a process that consumes
100% of the CPU if the statclock frequency is 128 Hz (which is the default
and not easy to change).  There is another overflow bug at 2^32 ticks = 388
days.  This one is harder to fix.  See PR 76972 for details and a fix for
the first overflow bug.

37965 seconds is a little larger than 305221 seconds.  The difference might
be due to the other 70000+ seconds being in ru_stime.

The behaviour when overflow occurs is undefined, but stopping on a value
is quite likely to occur due to the algorithm for updating ru_*time.
Integer overflow tends to cause counters to reset to 0 (or INT_MIN),
but the kernel enforces monotonicity of the usage times, so they will
stick instead of going backwards to 0.

Bruce
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"
Comment 3 Ed Maste freebsd_committer 2018-04-22 23:26:27 UTC

*** This bug has been marked as a duplicate of bug 76972 ***