[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hobbit] overflow in netbsd-meminfo.c
- To: hobbit (at) hswn.dk
- Subject: Re: [hobbit] overflow in netbsd-meminfo.c
- From: "Tracy Di Marco White" <gendalia (at) gmail.com>
- Date: Thu, 13 Nov 2008 08:17:46 -0600
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0Gi+V6nM/IsjvWMrASIg2Obzy4IE5UGYMFtO0gshn00=; b=VmSKmIK4tzusXIrZkOmv2v7d9Lwwhvac6x11sFORbb3V7Et3sUxD5SqksulrNxP0vi p+yr4XTDF3DpHyU+jX56m3Kh5fC7yNc3wMElqUWfEpeK63Rny1VPu+dtWg7EuX9B8NIc ycLc8ULGXVj+t3s4t5FQkZa7Vgm/Xowov5JPs=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Nq+fxhvt0Tm5AXJUuxpTwDb9aKE2sMmAeWayZWsGq0UnVKhEQTZtLtviK3GAIFfHUi IJ9W66xuBWkA1/l8RhBUzOYf0boBbQtH5nTM6d0gLn3aDtOx6oZh1MuO6qccL189ysP6 IbLOjVCTkOHQWx6nM7T02WXU1ZhMblH8RS8hA=
- References: <2193.1226548301 (at) satai.its.iastate.edu> <491BA7B9.8000806 (at) wi.rr.com> <7024c8c80811122027s2c0f8916uaa9b6e4cd1d45c02 (at) mail.gmail.com> <491BB067.9040609 (at) wi.rr.com> <7024c8c80811122109y555e995fxe4f9bd609f991878 (at) mail.gmail.com> <491C0E91.6090701 (at) wi.rr.com>
On Thu, Nov 13, 2008 at 5:25 AM, Rich Smrcina <rsmrcina (at) wi.rr.com> wrote:
> You posted this last night:
>
> Memory Used Total Percentage
> Physical 4294963639M 4294966523M 0%
> Swap 0M 4098M 0%
I said that was from hobbit, not from NetBSD. It's from the hobbit
display page which I assume is generated from the "client data"
information it has received, which is why I later included the
"meminfo" information from the client data, which is generated by the
hobbit client. The only thing directly generated by NetBSD that I've
included was the "sysctl -a|grep physmem" information.
> It appears that Hobbit is reading the 'physical' line, therefore causing the
> negative value in meminfo. If you have 4G of memory on your machine, the
> value is clearly wrong, so the error is in netbsd. Changing the Hobbit code
> isn't fixing the problem, it just makes the value more readable... :)
> Hobbit will still reflect a wrong memory value.
Was I wrong to assume that the hobbit display page
(bb-hostsvc.sh?HOST=hostname&SERVICE=memory) is generated from the
information the "client data" link on that page shows me, by hobbit?
My assumption was that the meminfo section of the client data page was
generated directly by the meminfo-netbsd.c program, since the printfs
seem to match. If that's the path the data takes, I still don't see
how this is a bug in NetBSD.
I also don't see how hobbit's meminfo-netbsd.c can be correct if it's
putting physmem in an int, when physmem is more than 2GB. The sysctl
-a output below I previously sent is correct. If a signed int is being
used, hw.physmem (= -537526272) has the proper bit pattern. physmem is
defined as an int in meminfo-netbsd.c. It is likely that
netbsd-meminfo.c should be using unsigned longs instead, or at least
unsigned int. The freebsd-meminfo.c uses an unsigned long, which made
sense for me to use in meminfo-netbsd.c, and at that point,
meminfo-netbsd.c could probably use hw.physmem64 instead of
hw.physmem.
-Tracy
> Tracy Di Marco White wrote:
>>
>> On Wed, Nov 12, 2008 at 10:43 PM, Rich Smrcina <rsmrcina (at) wi.rr.com> wrote:
>>
>> It looks like the problem is this, then?
>> # sysctl -a|grep physmem
>> hw.physmem = -537526272
>> hw.physmem64 = 3757441024
>>
>> But if hobbit is using a signed int, which it does seem to be here, I
>> don't see how hobbit could get it anything but wrong when there's more
>> than 2 GB of RAM.
>> Given this code, that's my understanding:
>> 25 int physmem;
>> 67 printf("Total:%d\n", (physmem / (1024 * 1024)));
>>
>> So is this also a bug in FreeBSD, as they are also using an unsigned
>> long, for this and for pagesize?
>>
>> Could you help me understand why you say this is a bug in NetBSD?