Date: Mon, 20 Aug 2007 01:23:34 +0300 From: Diomidis Spinellis <dds@aueb.gr> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: attilio@FreeBSD.ORG, jeff@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Crash in accounting code: encode_long(), due to bad rusage data? Message-ID: <46C8C2E6.9030405@aueb.gr> In-Reply-To: <20070819214953.I1099@fledge.watson.org> References: <20070819214953.I1099@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
> I recently upgraded two servers from FreeBSD 6-STABLE to FreeBSD
> 7-CURRENT in anticipation of the forthcoming release. Both of them run
> with accounting enabled at all times. When a large pine session was
> exiting on one of the two boxes, I ran into the following panic:
>
> panic: encode_long: -ve value -32749
Getting rid of the panic is easy:
--- kern_acct.c 2007-08-20 01:15:18.000000000 +0300
+++ kern_acct.c.new 2007-08-20 01:16:06.000000000 +0300
@@ -523,8 +523,7 @@
int norm_exp; /* Normalized exponent */
int shift;
- KASSERT(val >= 0, ("encode_long: -ve value %ld", val));
- if (val == 0)
+ if (val <= 0)
return (0);
norm_exp = fls(val) - 1;
shift = FLT_MANT_DIG - norm_exp - 1;
However, as you wrote, this doesn't fix the root of the problem.
> I find the large negative value in ru_idrss somewhat sad to contemplate,
> and while this could well be a problem with capturing of process runtime
> information, I'd like it if the accounting code were robust against this
> sort of bug, rather than panicking, and I guess I'd also rather than the
> process runtime information also be correctly captured :-).
Do you think it makes any sense for encode_long to be correctly encoding
negative numbers, or should we concentrate on locating and fixing the
negative ru_idrss problem?
Diomidis Spinellis - http://www.spinellis.gr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46C8C2E6.9030405>