RAM informations are wrong on Darwin OS

[JoffreyPoreeCoding]

Hello,

I'm using Mac OS 10.15.6 (Catalina) and getRam function return incorrect result.

Here explained :

use Linfo\Linfo;

require 'vendor/autoload.php';

$linfo = (new Linfo())->getParser();

print_r($linfo->getRam());

Result :

Array
(
    [type] => Physical
    [total] => 17179869184
    [free] => 17432133632
    [swapTotal] => 0
    [swapFree] => 0
    [swapInfo] => Array
        (
        )

)

As you can see, free mem is greater than available. sysctl hw.usermem return `hw.usermem: -216473600'. So I try to take only the absolute value (216473600) but it still wrong.

My current free RAM is about 3Gb.

A little trick allow me to get the free RAM in Dawin.php (I don't like to "unitPows trick but... it works)

$freeMemory = trim($this->exec->exec('top', '-l 1 | grep PhysMem | sed "s/.*, //" | sed "s/ .*//"'));
$unitPows = [
    'K' => 1,
    'M' => 2,
    'G' => 3,
];

$unit = substr($freeMemory, -1);
$freeMemory = (int) $freeMemory;
$freeMemory = $freeMemory * pow(1024, $unitPows[$unit]);

Gives me 2008023040 (2Gb because my RAM available is about 2Gb ^^)

Hope you will find a fix with sysctlvelse I can make a merge request to put modification.

[jrgp]

Hey,

Thanks for the report.

This problem is likely due to the mac sysctl entries being bounded by the size of a 32bit integer, which is why the value for hw.usermem overflowed and became negative. This wasn't caught when the Linfo Darwin OS class was written 10 years ago as computers had less ram back then.

The proper fix here is to have Linfo execute vm_stat and regex-match out the right values, as opposed to the current implementation which tries extract the info from sysctl.

While the top shell pipeline approach would work, it's more efficient to execute just one command (vm_stat) as opposed to executing 4.

[JoffreyPoreeCoding]

Yeah sure it's better to use vm_stat, will you fix it soon ?

[jrgp]

Per 6ce928401af5dda50d35f9669fbb45bb8b617570 I've committed a patch that "fixes" the value being reported as negative.

It still isn't accurate though as it doesn't take into account memory which is used for filesystem cache nor compressed memory regions

[JoffreyPoreeCoding]

Ok nice, thanks you!