pstat_getprocvm - finding what's being used by the regions

[Tony Chou]

As a part of diagnosing a memory leak problem, I must find out what each region holds in a process. For example, can a shared library get loaded into the regions.

I need a way to identify (printable names) from these regions about what they are. Are you aware of a function that can do this?

Thanks in advance for your help!

Tony Chou

P.S.This thread has been moved from HP-UX>System Administration to HP-UX > languages- HP Forums Moderator

[Steven Gillard_2 · Accepted solution]

The "memory regions" screen in glance gives you names and details of all memory regions for a process, including file names when a file is mmap'd there.

If you need to use the pstat* syscalls to get this information, you might try the pstat_getfiledetails() call using the pst_fid field of the structure thats returned from pstat_getprocvm(). Once you have that, you've effectively got the inode number and the file name is only a short ftw() (or find) away.

Regards,
Steve

[Tony Chou]

Thanks so very much for your help! Is pstat_getfiledetails a function only supported in 11i? I don't seem to be able to do this.

If that's the case, could you recommend other routes? When I check glance it showed me the inodes but I don't know how to read them since they are abbreviated...

[Mike Stroyan]

Here is a program that uses pstat_procvm and looks up file paths by matching the fields from the pst.pst_id field returned for each region. This works on 11.00.

It does not file-tree-walk from every mount point, but instead does a faster search from data read in advance using nftw on a limit list of directories.

Shared libraries actually load into up to three regions each. There is a separate region for text, initialized data, and uninitialized (BSS) data.

[Dietmar Konermann]

Tony,

install PHCO_28067 (11.11) and try the tool /usr/contrib/Q4/bin/kmeminfo. Especially the -user and the -pid options should help you finding your leak.

Best regards...
Dietmar.

[Tony Chou]

You are amazing! Thanks a bunch for the pointers. The program really helped out.

Since I'm not a sys admin, there is one thing I need to learn.

I was able to run kmeminfo.11.00 but it complained about this:
libp4 (4.14):Opening /stand/vmunix /dev/kmem
I'm guessing that I must be a root to run this?

Thanks again for your help. Have a great day!

Sincerely,
Tony

[Tony Chou]

Well I'm back again.

When one memory region grows over time, does it mean the shared library in that region is responsible for the growth? What I'm seeing now is that there is no memory growth in the memory region in which the shared library resides but in the memory region in which the main program resides.

Thanks!

[Dietmar Konermann]

Hi, Tony!

You are right. You need read access to /dev/kmem. A normal user should not have that. :-)

Your pregions have several types (TEXT, DATA, MMAP, STACK, etc.). When a shared library is used then this is typically MMAP and holds the libraries text. Your process's private memory allocations come from DATA pregions.

Usually a memory leaking user process leads to an increasing DATA segment. Also dynamic allocations done by shared librariy code.

Best regards...
Dietmar.

[Tony Chou]

Thanks very much for all of your help. We have reached a conclusion on the module of the leak and opened a case with the vendor. I really appreciate the directions you gave to me on this investigation. Thank you again.

Tony