[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) iastate.edu>
- Date: Wed, 12 Nov 2008 23:09:11 -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:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=qW6emIH2EihWH+hLAXJs78yb6STcR9niFI2PhcJC9pA=; b=Z9fO1pOLFV6MddXTHiZKyyu4keT/SS+UI2jcUXxq8MrPQGSSls/i/zRMX8Fds/kLLl HgomKWrezBLiwRREIGMG+bDZnuyWd9B47n9smEZAZLoqfYlXsM3RDvdFVw/lbCcTBxz5 SEiXVIdkkiwiTL0nJeYp9kMIdkmOslwEc2WiE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ejVxiJZ53MgQmHLPeqoGShcCPWULCwhrOSu35r5VRONIyrWRImO7vm0psMkj+KhlIP LFgDT6e2BU0EQas0sW6894r4niJCCyS3AqFtme4ZlZ1t1GZn8/GCWuePkAtw5jHqDboX jazgO7BwCJv05Vd8csM1spWcvTTcc0R9GujMk=
- 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>
On Wed, Nov 12, 2008 at 10:43 PM, Rich Smrcina <rsmrcina (at) wi.rr.com> wrote:
> Tracy Di Marco White wrote:
>>>
>>> That appears to be a bug in netbsd.
>>
>> This is what it appears as in meminfo for one of my 4GB machines:
>> [meminfo]
>> Total:-773
>> Free:2884
>> Swaptotal:4098
>> Swapused:0
>>
>> Since freebsd-meminfo.c seems to be using unsigned long in the same
>> place I modified it, I'm not sure it's a bug only in NetBSD.
>
> The display is a bug, Hobbit's interpretation and use of it is an artifact
> of the bug.
>
> If netbsd doesn't have a fix for this problem, you're patch is the right
> solution.
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?
-Tracy