HP-UX HB v13.00 Ch-11 - Software Development

HP-UX Handbook Rev 13.00 Page 81 (of 101)
Chapter 11 Software Development
October 29, 2013
brk(2): process heap (private)
mmap(2): memory mapped regions (private or shared)
shmget(2): System V shared memory
If we don’t know how the process makes use of its address space, we can either use tusc(1) to
check which of the above system calls it executes, or look at the current usage of the process
address space with kmeminfo or glance(1). If the process has already died and left a core file,
we can use the $m command of adb(1) to get a similar output as kmeminfo:
tusc s brk,mmap,shmget <PID>
kmeminfo pid <PID>
echo ‘$m‘ | adb <program> <core file>
System calls that fail to allocate memory set errno=ENOMEM which is shown by tusc(1) as
return code. This can either be the result of a memory leak, or the program might really need
more memory to execute properly.
If memory allocation with brk(2) fails, we need to look at ulimit d (see sh-posix(1)) and
maxdsiz[_64bit]. Increase the kernel parameter with kmtune(1M) to match the process
requirements. The initial ulimit will reflect these changes automatically.
For mmap(), a system call trace shows if the mapping was private or shared:
mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, NULL) ................... = 0x7dfea000
^^^^^^^^^^^ => Q2 (private)
mmap(NULL, 4096, PROT_READ|PROT_EXEC,
MAP_SHARED|MAP_SHLIB, 3, 0x1000) ....................... = 0xc0004000
^^^^^^^^^^ => Q4 (shared)
The returned addresses confirm this, as the mappings go into different quadrants.
There are no kernel parameters or other virtual limits that restrict the usage of mmap(2). The only
limits are the process address space and the system wide available virtual memory.
Process heap, process stack and privately mapped regions all reside in the private data quadrants.
If a program gets ENOMEM from brk() although the heap size has not reached the ulimit or
maxdsiz, or if it cannot map another private region, then it ran out of private address space. The
free private address space of a running process can be calculated from a kmeminfo output:
$ kmeminfo pid <PID>