overflow in netbsd-meminfo.c
list Tracy di Marco White
Hobbit client 4.2.0 shows things like this on machines I have
with 4GB of RAM:
Memory Used Total Percentage
Physical 4294963639M 4294966523M 0%
Swap 0M 4098M 0%
With this patch it's better:
--- client/netbsd-meminfo.c.orig 2008-11-12 19:25:30.000000000 -0600
+++ client/netbsd-meminfo.c
@@ -22,7 +22,7 @@ static char rcsid[] = "$Id: netbsd-memin
int main(int argc, char *argv[])
{
int hw_physmem[] = { CTL_HW, HW_PHYSMEM };
- int physmem;
+ unsigned long physmem;
int hw_pagesize[] = { CTL_HW, HW_PAGESIZE };
int pagesize;
Tracy J. Di Marco White
Information Technology Services
Iowa State University
list Rich Smrcina
▸
Tracy Di Marco White wrote:
Hobbit client 4.2.0 shows things like this on machines I have
with 4GB of RAM:
Memory Used Total Percentage
Physical 4294963639M 4294966523M 0%
Swap 0M 4098M 0%
With this patch it's better:
--- client/netbsd-meminfo.c.orig 2008-11-12 19:25:30.000000000 -0600
+++ client/netbsd-meminfo.c
@@ -22,7 +22,7 @@ static char rcsid[] = "$Id: netbsd-memin
int main(int argc, char *argv[])
{
int hw_physmem[] = { CTL_HW, HW_PHYSMEM };
- int physmem;
+ unsigned long physmem;
int hw_pagesize[] = { CTL_HW, HW_PAGESIZE };
int pagesize;
Tracy J. Di Marco White
Information Technology Services
Iowa State University
That appears to be a bug in netbsd. -- Rich Smrcina VM Assist, Inc. Phone: XXX-XXX-XXXX Ans Service: XXX-XXX-XXXX http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
list Tracy di Marco White
▸
On Wed, Nov 12, 2008 at 10:06 PM, Rich Smrcina <user-cf452ff334e0@xymon.invalid> wrote:
Tracy Di Marco White wrote:Hobbit client 4.2.0 shows things like this on machines I have with 4GB of RAM: Memory Used Total Percentage Physical 4294963639M 4294966523M 0% Swap 0M 4098M 0% With this patch it's better: --- client/netbsd-meminfo.c.orig 2008-11-12 19:25:30.000000000 -0600 +++ client/netbsd-meminfo.c @@ -22,7 +22,7 @@ static char rcsid[] = "$Id: netbsd-memin int main(int argc, char *argv[]) { int hw_physmem[] = { CTL_HW, HW_PHYSMEM }; - int physmem; + unsigned long physmem; int hw_pagesize[] = { CTL_HW, HW_PAGESIZE }; int pagesize;
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. -Tracy
list Rich Smrcina
▸
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.
▸
-- Rich Smrcina VM Assist, Inc. Phone: XXX-XXX-XXXX Ans Service: XXX-XXX-XXXX http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
list Tracy di Marco White
▸
On Wed, Nov 12, 2008 at 10:43 PM, Rich Smrcina <user-cf452ff334e0@xymon.invalid> 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
list Brian Scott
Isn't this a case of netbsd returning a perfectly valid number that meminfo has misinterpreted as a negative number (-773). Hobbit has then seen the negative number and incorrectly handled it as a very large positive number. Netbsd doesn't appear to have a bug based on this evidence. Offcourse if netbsd is returning a negative number to meminfo then they do have a bug. However, since the bug in the meminfo code could easily have caused the error seen, we can't know if netbsd also has the same bug. If the fix to meminfo works (and I'm guessing it does) then it's pretty solid proof that there isn't an underlying problem in netbsd. I don't have a copy of netbsd to double check this. Regards, Brian Scott
▸
-----Original Message-----
From: Rich Smrcina [mailto:user-cf452ff334e0@xymon.invalid]
Sent: Thursday, 13 November 2008 3:43 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] overflow in netbsd-meminfo.c
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. -- Rich Smrcina VM Assist, Inc. Phone: XXX-XXX-XXXX Ans Service: XXX-XXX-XXXX http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 **********************************************************************
This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**********************************************************************
list Rich Smrcina
You posted this last night:
▸
Memory Used Total Percentage
Physical 4294963639M 4294966523M 0%
Swap 0M 4098M 0%
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.
▸
Tracy Di Marco White wrote:On Wed, Nov 12, 2008 at 10:43 PM, Rich Smrcina <user-cf452ff334e0@xymon.invalid> 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?
-Tracy
-- Rich Smrcina VM Assist, Inc. Phone: XXX-XXX-XXXX Ans Service: XXX-XXX-XXXX http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
list Tracy di Marco White
▸
On Thu, Nov 13, 2008 at 5:25 AM, Rich Smrcina <user-cf452ff334e0@xymon.invalid> 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 <user-cf452ff334e0@xymon.invalid> 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?
list Rich Smrcina
▸
Tracy Di Marco White wrote:
On Thu, Nov 13, 2008 at 5:25 AM, Rich Smrcina <user-cf452ff334e0@xymon.invalid> 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.
<egg-on-face> Ugh! My apologies, Tracy. For some reason, I thought that was from NetBSD. I guess I should read slower... :) </egg-on-face>
▸
-- Rich Smrcina VM Assist, Inc. Phone: XXX-XXX-XXXX Ans Service: XXX-XXX-XXXX http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
list Tracy di Marco White
▸
On Thu, Nov 13, 2008 at 8:59 AM, Rich Smrcina <user-cf452ff334e0@xymon.invalid> wrote:
Tracy Di Marco White wrote:On Thu, Nov 13, 2008 at 5:25 AM, Rich Smrcina <user-cf452ff334e0@xymon.invalid> 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.<egg-on-face> Ugh! My apologies, Tracy. For some reason, I thought that was from NetBSD. I guess I should read slower... :) </egg-on-face>
No problem, I just wasn't sure of what was wrong when I sent that. Your mail made me search harder to make sure I understood what was going on, which isn't a bad thing. And comparing to FreeBSD's helped too. In freebsd-meminfo.c, pagesize is an unsigned long also (as is physmem). I don't expect pagesize on NetBSD to be more than max int any time soon, but should I also change that in netbsd-meminfo.c, where it's also an int? (I'm planning to include this patch in the pkgsrc hobbitclient update I'm going to do as soon as I'm relatively sure this is mostly correct. It would also be nice to have integrated for some future release of hobbit/xymon as well.) -Tracy