SCO OS 6 Returns Negative Memory
list Jamison Maxwell
I'm having an issue where I've got one OpenServer 6 box that returns a negative value for the memory test, this is on 4.3.11. I'm not really sure where to start looking. Client Data: [memsize] 4294496256 [freemem] Average 968749 1582626 193182 733337 [swap] path dev swaplo blocks free /dev/swap 7679,1 0 5515256 5515256 I see in the client script that the result is based off of the output from 'sar -r 1 2 | tail -1'. Here's output from sar minus the tail: 13:21:56 freemem freeswap freekv filemem 13:21:57 968176 1583206 193184 732722 13:21:58 968088 1583206 193184 732676 Average 968132 1583206 193184 732699 What's actually reported is: Physical -3782M 0M 0% Swap 0M 2692M 0% Anyone know where to start? Jamison Maxwell user-87d336c3dce6@xymon.invalid
list Jeremy Laidman
On 3 May 2013 04:11, Jamison Maxwell <user-87d336c3dce6@xymon.invalid> wrote:
4294496256
Yes, this is bigger than what atoi() will return. This is done in
xymond/client/sco_sv.c in the function handle_sco_sv_client() in the
following line of code:
memphystotal = (atoi(memsizestr) / 1048576);
The variable memsizestr is a string pointer to the value in the [memsize]
client data section. The variable memphystotal is defined as a long, so it
would make sense that atol() be used instead of atoi().
This is probably a bug in Xymon, but I'm not a C coder so I'm not entirely
sure. However, the [memsize] section is only parsed for (and sent by)
SCO/Unixware systems, which isn't exactly the most popular OS around. As
far as I can tell, it's the only client parsing code that uses atoi() for
memory numbers, and has probably rarely been used on SCO systems with
sufficient memory size to overflow the signed integer type (about 2.1GB).
Henrik, agree that this is a bug?
Cheers
Jeremy
list Henrik Størner
On Fri, 3 May 2013 13:14:17 +1000, Jeremy Laidman
▸
<user-71895fb2e44c@xymon.invalid> wrote:On 3 May 2013 04:11, Jamison Maxwell <user-87d336c3dce6@xymon.invalid> wrote:4294496256Yes, this is bigger than what atoi() will return. This is done in xymond/client/sco_sv.c in the function handle_sco_sv_client() in the following line of code: memphystotal = (atoi(memsizestr) / 1048576); The variable memsizestr is a string pointer to the value in the
[memsize]
client data section. The variable memphystotal is defined as a long, so it would make sense that atol() be used instead of atoi(). This is probably a bug in Xymon, but I'm not a C coder so I'm not entirely sure. However, the [memsize] section is only parsed for (and sent by) SCO/Unixware systems, which isn't exactly the most popular OS around.
As
far as I can tell, it's the only client parsing code that uses atoi() for memory numbers, and has probably rarely been used on SCO systems with sufficient memory size to overflow the signed integer type (about
2.1GB).
Henrik, agree that this is a bug?
Sounds like it. It's the first bug report on the SCO client that I can recall, so as you say - probably not the most widely tested piece of code. Changing that line to use "atol" instead of "atoi" sounds like a simple and valid solution. Perhaps Jamison could try that and let us know if it solves the problem ? Regards, Henrik
list Jamison Maxwell
Also, I'm using your remote client, Jeremy. It's a huge help and I recommend it to everyone. Jamison Maxwell p. XXX XXX XXXX user-87d336c3dce6@xymon.invalid<mailto:user-87d336c3dce6@xymon.invalid>
▸
From: Jeremy Laidman [user-71895fb2e44c@xymon.invalid]
Sent: Thursday, May 02, 2013 11:14 PM
To: Jamison Maxwell
Cc: xymon at xymon.com; Henrik Størner
Subject: Re: [Xymon] SCO OS 6 Returns Negative Memory
On 3 May 2013 04:11, Jamison Maxwell <user-87d336c3dce6@xymon.invalid<mailto:user-87d336c3dce6@xymon.invalid>> wrote:
4294496256
Yes, this is bigger than what atoi() will return. This is done in xymond/client/sco_sv.c in the function handle_sco_sv_client() in the following line of code:
memphystotal = (atoi(memsizestr) / 1048576);
The variable memsizestr is a string pointer to the value in the [memsize] client data section. The variable memphystotal is defined as a long, so it would make sense that atol() be used instead of atoi().
This is probably a bug in Xymon, but I'm not a C coder so I'm not entirely sure. However, the [memsize] section is only parsed for (and sent by) SCO/Unixware systems, which isn't exactly the most popular OS around. As far as I can tell, it's the only client parsing code that uses atoi() for memory numbers, and has probably rarely been used on SCO systems with sufficient memory size to overflow the signed integer type (about 2.1GB).
Henrik, agree that this is a bug?
Cheers
Jeremy
list Jamison Maxwell
Works like a charm! Thanks so much Henrik and Jeremy! Jamison Maxwell user-87d336c3dce6@xymon.invalid
▸
From: user-ce4a2c883f75@xymon.invalid [user-ce4a2c883f75@xymon.invalid]
Sent: Friday, May 03, 2013 4:48 AM
To: Jeremy Laidman
Cc: Jamison Maxwell; xymon at xymon.com
Subject: Re: [Xymon] SCO OS 6 Returns Negative Memory
On Fri, 3 May 2013 13:14:17 +1000, Jeremy Laidman
<user-71895fb2e44c@xymon.invalid> wrote:On 3 May 2013 04:11, Jamison Maxwell <user-87d336c3dce6@xymon.invalid> wrote:4294496256Yes, this is bigger than what atoi() will return. This is done in xymond/client/sco_sv.c in the function handle_sco_sv_client() in the following line of code: memphystotal = (atoi(memsizestr) / 1048576); The variable memsizestr is a string pointer to the value in the
[memsize]
client data section. The variable memphystotal is defined as a long, so it would make sense that atol() be used instead of atoi(). This is probably a bug in Xymon, but I'm not a C coder so I'm not entirely sure. However, the [memsize] section is only parsed for (and sent by) SCO/Unixware systems, which isn't exactly the most popular OS around.
As
far as I can tell, it's the only client parsing code that uses atoi() for memory numbers, and has probably rarely been used on SCO systems with sufficient memory size to overflow the signed integer type (about
2.1GB).
Henrik, agree that this is a bug?
Sounds like it. It's the first bug report on the SCO client that I can recall, so as you say - probably not the most widely tested piece of code. Changing that line to use "atol" instead of "atoi" sounds like a simple and valid solution. Perhaps Jamison could try that and let us know if it solves the problem ? Regards, Henrik