Re: Crash in accounting code: encode_long(), due to bad rusage data?

On Sun, 19 Aug 2007, Jeff Roberson wrote:

>>> (kgdb) list
>>> 386             tmp = ut;
>>> 387             timevaladd(&tmp, &st);
>>> 388             /* Convert tmp (i.e. u + s) into hz units to match ru_i*. 
>>> */
>>> 389             t = tmp.tv_sec * hz + tmp.tv_usec / tick;
>>> 390             if (t)
>>> 391                     acct.ac_mem = encode_long((ru.ru_ixrss + 
>>> ru.ru_idrss +
>>> 392                         + ru.ru_isrss) / t);
>>> 393             else
>>> 394                     acct.ac_mem = 0;
>>> 395
>>> (kgdb) inspect ru
>>> $2 = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0,
>>>    tv_usec = 0}, ru_maxrss = 509908, ru_ixrss = 26810576,
>>>  ru_idrss = -2016077424, ru_isrss = 1044992, ru_minflt = 372535,
>>>  ru_majflt = 42, ru_nswap = 0, ru_inblock = 58, ru_oublock = 278,
>>>  ru_msgsnd = 1907, ru_msgrcv = 4671, ru_nsignals = 32, ru_nvcsw = 19892,
>>>  ru_nivcsw = 4614}
>
> Can you tell me what's in t, tmp, hz and tick?

For the benefit of those not present for my conversation with Jeff, here are 
the values:

(kgdb) inspect t
$1 = {tv_sec = 94826, tv_usec = 91516}
(kgdb) inspect hz
$2 = 1000
(kgdb) inspect tick
$3 = 1000
(kgdb) inspect tmp
$4 = 0

Robert N M Watson
Computer Laboratory
University of Cambridge