site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Kevin, I've gotten feedback from a number of users that the large number being reported also causes their systems to lock up completely. It's not just a printf problem. Here's the source code for the function in question: unsigned long long GetFreeMem() { vm_statistics_data_t vm_stat; mach_port_t host_priv_port, host_port; mach_msg_type_number_t host_count; kern_return_t kern_error; unsigned long long FreeMem; // Free real (physical) memory // Get host machine information mach_port_t get_host_priv() { return(mach_host_self()); } mach_port_t get_host_port() { return(mach_host_self()); } // Get total system-wide memory usage structure host_priv_port = get_host_priv(); host_port = get_host_port(); host_count = sizeof(vm_stat)/sizeof(integer_t); kern_error = host_statistics(host_priv_port, HOST_VM_INFO, (host_info_t)&vm_stat, &host_count); if (kern_error != KERN_SUCCESS) { mach_error("host_info", kern_error); exit(EXIT_FAILURE); } host_page_size(host_port, &mac_pagesize); // Get page size for this machine FreeMem = ((unsigned long long) vm_stat.free_count) * mac_pagesize; // Calculate total free memory in bytes FreeMem &= 0xFFFFFFFFFFFFFFC0ull; // Align byte count to 64-byte boundary return(FreeMem); } I need to have the correct number of bytes returned to the calling function in both 32-bit and 64-bit modes. This code works correctly in 32-bit environments but is breaking on 64-bit platforms. Thanks, Tony --- Kevin Van Vechten <kevin@opendarwin.org> wrote:

Perhaps the problem is with the format string used to print the number instead of with the number itself?

Would someone mind pointing me to the specific source file in question?

Thanks,

- Kevin

On Jun 1, 2005, at 6:23 AM, Tony Scaminaci wrote:

...

...

From: Tony Scaminaci <friskythecat@sbcglobal.net> Date: June 1, 2005 8:18:31 AM CDT To: William Kucharski <kucharsk@mac.com> Cc: Tony Scaminaci <friskythecat@sbcglobal.net> Subject: Re: 64-bit problem with VM statistics

Unfortunately, this is the exact line that's NOT working on 64-bit platforms. FreeMem is returning with the following:

Available memory: 268267683840MB (281299054850211840 bytes)

The number of bytes (which is what FreeMem is holding) is way too large. It should be around 4613734400 bytes on this particular machine which has about 4400 MB free as shown by top.

I received a bug post from John Caldwell who flagged this line of code as having a sign extension issue. He indicated that the correct way to implement this is to cast vm_stat.free_count to an unsigned 32-bit first, then cast the result to an unsigned long long. I'm still not sure of the correct coding and order of typecasting though since he didn't give an example.

Tony

On Jun 1, 2005, at 1:32 AM, William Kucharski wrote:

...

On May 31, 2005, at 1:28 PM, Tony Scaminaci wrote:

...

The following calculation of free memory (in bytes) works correctly on 32-bit platforms. On 64-bit systems (Tiger + G5), the result is a horrendously huge number rather than what is expected. I'm sure this is one of the conversion issues covered in the 64-bit transition guide (which I've read over multiple times already) but I can't seem to nail down the right way to do this calculation for both 32 and 64-bit systems.

vm_size_t mac_pagesize; unsigned long long FreeMem; // Free real (physical) memory in bytes

What's the "horrendously huge" number?

The correct way to do this is to cast the number of pages to an unsigned long long and multiply it by mac_pagesize, so the initial code sample you had:

FreeMem = ((unsigned long long) vm_stat.free_count) * mac_pagesize;

should work just fine on all architectures.

William Kucharski kucharsk@mac.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com