This was tested on Ubuntu x64 10.04
64bit AMD with 3Gigs of RAM

Linux.SysInfo(@SI);
Load_Ram:=(100-Trunc(100 * SI.freeram / SI.totalram));

Si.totalram checks out ok. SI.freeram never seems to be accurate.

The numbers returned here do not correspond to that of System Monitor for the same user.
When using sudo ./startlazarus and debugging process (I'm debugging project that requires low port numbers) the numbers are even more off.

What is the problem with Linux? Windows GlobalMemoryStatus works just fine.

This function is essential for server management and trouble shooting.

In our previous episode, Andrew Brunner said:

Windows api doesn't fluctuate so much with time.

This function is essential for server management and trouble shooting.

Maybe they changed the record. I'm not sure it even was validated for 64-bit

The simplest way to debug this is to make a minimal C program using the function, and then check the size of the record. If that is ok, check if the libc function does more than just passing all params on to the call.

I got indications that something changed on Debian (also on 32-bit), but wasn't able to reproduce it

http://bugs.freepascal.org/view.php?id=13521

the reporters there seem to indicate that it goes wrong with 2GB+ ram.

Are the numbers returned by SysInfo() similar to those returned by Linux's 'free' program and 'top'? Are you taking into account that your program, and in particular the Lazarus IDE, are going to be reducing the amount of free memory significantly?

Hi Mark,

The SysInfo function should only return information that is OS specific. Things like CPU load and Memory Stats. So the SysInfo function should return values, in real-time, up to date, and matching that of a tool like gnome-system-monitor. The SysInfo function running on my distro returns numbers that don't seem to coorelate to anything I can point to as the culprit.

They aren't random but they aren't accurate ?!? LOL.

According to the man page, the sysinfo structure hasn't changed in 10 years?

Henry Vermaak wrote

According to the man page, the sysinfo structure hasn't changed in 10 years?

Ok, That's the culprit. 10 years ago we had bill gates telling the world 640KB was enough (about the time Al Gore was inventing the Internet). The structure needs to be upgraded to include data past 2gigs. Someone has to figure out what it was changed to. It's obvious that gnome-system-monitor was able to poll and get the proper values.

Anyone with more SysInfo details on what it may have been replaced with? Updated calling conventions?

Andrew Brunner wrote

Anyone with more SysInfo details on what it may have been replaced with?  Updated calling conventions?

Can you please write a small c app that returns all the sysinfo values? Then we can figure out if the problem is with fpc.

Henry

In our previous episode, Henry Vermaak said:

Manpage:

Since Linux 2.3.23 (i386), 2.3.48 (all architectures) the structure is:

struct sysinfo {
long uptime; /* Seconds since boot */
unsigned long loads[3]; /* 1, 5, and 15 minute load averages */
unsigned long totalram; /* Total usable main memory size */ unsigned long freeram; /* Available memory size */ unsigned long sharedram; /* Amount of shared memory */ unsigned long bufferram; /* Memory used by buffers */ unsigned long totalswap; /* Total swap space size */ unsigned long freeswap; /* swap space still available */ unsigned short procs; /* Number of current processes */ unsigned long totalhigh; /* Total high memory size */ unsigned long freehigh; /* Available high memory size */ unsigned int mem_unit; /* Memory unit size in bytes */ char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding for libc5 */

           };

and the sizes are given as multiples of mem_unit bytes.

FPC was updated for this in 8330 (somewhere in 2007, probably part of 2.2.4 and 2.4.0)

On Fri, 19 Mar 2010 14:45:29 +0000, Henry Vermaak wrote about Re: [fpc-devel] Linux.SysInfo Problem:

You will also need to take into account the differences between 32-nit and 64-bit platforms. The struct sysinfo declarations use "unsigned long" for most of the fields, but the size of that varies with platform: on a 32-bit platform unsigned long is a DWORD; on a 64-bit platform unsigned long is a QWORD.

That's why fpc has this in ctypes:

{$ifdef cpu64}
  clong                  = int64;              pclong                 = ^clong;
  cslong                 = int64;              pcslong                = ^cslong;
  culong                 = qword;              pculong                = ^culong;
{$else}
  clong                  = longint;            pclong                 = ^clong;
  cslong                 = longint;            pcslong                = ^cslong;
  culong                 = cardinal;           pculong                = ^culong;
{$endif}

Henry

These are the important fields:

unsigned long totalhigh; /* Total high memory size */ unsigned long freehigh; /* Available high memory size */ unsigned int mem_unit; /* Memory unit size in bytes */

and they were added to FPC in 2007 via this bugreport:

http://bugs.freepascal.org/view.php?id=9523