Crash in accounting code: encode_long(), due to bad rusage data?
Robert Watson
rwatson at FreeBSD.org
Mon Aug 20 12:36:05 PDT 2007
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
More information about the freebsd-current
mailing list