Works like a charm! Thanks so much Henrik and Jeremy!
Jamison Maxwell jamison at newasterisk.com
From: henrik at hswn.dk [henrik at hswn.dk] 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 <jlaidman at rebel-it.com.au> wrote:
On 3 May 2013 04:11, Jamison Maxwell <jamison at newasterisk.com> 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?
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