Memory usage code

[porwaa]

Hi I have used the below code to get the memory usage of a process on a HP PA RISC system.
This process on loads several shared libraries on demand.
The system call is being made in one of the shared libraries that is meant for logging purpose. It is here that the below code is leveraged to get the memory statitiscs. Unfortunately the output coming out of it is too large in terms of the number of bytes. This does not equate to the current size of process memory .
Could it be
1) wrong usage of format specifiers and variables which could lead to overflow or something else

struct pst_vm_status pst;
int idx, count;
size_t sys_page_size;
sys_page_size = sysconf(_SC_PAGE_SIZE);

long long shared_vm = 0;
long long shared_ram = 0;
long long private_vm = 0;
long long private_ram = 0;
idx=0;
count = pstat_getprocvm(&pst, sizeof(pst), getpid(), idx);
while (count > 0)
{

switch ((long)pst.pst_type) {
case PS_IO: break;
/* Don't count IO space. It really is not RAM or swap. */
default:
if (pst.pst_flags & PS_SHARED) {
shared_vm += (long long) pst.pst_length;
shared_ram += (long long)pst.pst_phys_pages;
} else {
private_vm += (long long) pst.pst_length;
private_ram += (long long)pst.pst_phys_pages;
}
break;
}

idx++;
count = pstat_getprocvm(&pst, sizeof(pst), getpid(), idx);

[Don Morris_1]

Unterminated while loop as posted.

So... you don't really say what's considered the output. Is this returning private_vm? private_ram? Are these globals read elsewhere (and if so -- what happens if more than one client is using the library at a time)?

Certainly since the length and number of pages are both in pages and HP-UX platforms currently max out at 44-bit physical addressing / 50-bit virtual addressing, the variables you've shown should be no worse than 32-bits physical and 38 bits virtual.

uname -a ? (i.e. what version of the OS are you running this on?)

Do you get any difference if the library and application are compiled with -D_PSTAT64 assuming they are 32-bit? That would probably do it, by the way -- without -D_PSTAT64, these fields are _T_LONG_T which becomes just int32_t. Casting to long long would sign extend a full 32-bit value.

[porwaa]

Unterminated while loop as posted.
[]- while loop is ok . I m issed the terminating }

So... you don't really say what's considered the output. Is this returning private_vm? private_ram? Are these globals read elsewhere (and if so -- what happens if more than one client is using the library at a time)?
[]I'm concerned about the memory leak. So I guess I should be concerned about shared ram and private ram.
Also the the library is used by this process only.
These figures comes out to be good when I use this code in a samll application. Our enterprise app is one that loads the sl files one by one and this code is part of one of those sl files. My first questions is whether is it possible at all to use the above code in such an environment.

Certainly since the length and number of pages are both in pages and HP-UX platforms currently max out at 44-bit physical addressing / 50-bit virtual addressing, the variables you've shown should be no worse than 32-bits physical and 38 bits virtual.

uname -a ? (i.e. what version of the OS are you running this on?)
HP-UX irhp11a B.11.11 U 9000/800 999245507 unlimited-user license


Do you get any difference if the library and application are compiled with -D_PSTAT64 assuming they are 32-bit? That would probably do it, by the way -- without -D_PSTAT64, these fields are _T_LONG_T which becomes just int32_t. Casting to long long would sign extend a full 32-bit value.

[]# if defined(_PSTAT64)
# define _T_ULONG_T uint64_t
# define _T_LONG_T int64_t
# else
# define _T_ULONG_T uint32_t
# define _T_LONG_T int32_t
# endif

Aboveb is the conditional macro defination. I would like to know that on a 32 bit platform what is the equivalent of long long as in above. Should the usage os long long cause an overflow. Note that the value that comes for phsical memory by top command is about 30 MB when the above program o/p shows the below figures.
[1745818832][1745818784][1745818736][1745818688.
I'm assuning that the page size is 4 KB.

[Dennis Handly]

>I'm concerned about the memory leak.

Probably all you need is to call sbrk(0). Or use mallinfo(3).

If you want to track a memory leak, you should use gdb's leak detection commands.

>what is the equivalent of long long as in above

int64_t is the base type long long.

>should the usage of long long cause an overflow.

Nor sure how, if you are talking about bytes used.

[porwaa]

Actually I want to log the statistics of memory with the help of above program.Let me know whether I can use the above program to get the memory usage and if yes what field out of four should give an indicattion of memory which could be used for indicating a leak. Please note that the application loads the libraries.

[Don Morris_1]

The code _should_ be fine... again, though if you'd show where you _use_ the variables it would help. (Just printfs for now? If so, what's the format string there?) The only caveat I can think of is that the Shared physical pages reported via pstat is a fraction of the total for a given shared object based on the number of processes attached (so that the total shared pages across all attachers adds up and to give a concept of your 'share' of the memory). Not going to have anything to do with your large values issue -- but worth a mention.

The simplest thing to do is to not try to guess and cast things. You obviously include the pstat header -- use _T_LONG_T as the type for your summation variables and lose the casts.