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

HP-UX Handbook – Rev 13.00 Page 80 (of 101)
Chapter 11 Software Development
October 29, 2013
(gdb) thread 1
[Current thread is already 1 (system thread 3785)]
(gdb) bt
Thread 1 (system thread 10567):
#0 0x7efa5cac in printf+0x18 () from /usr/lib/libc.2
#1 0x29f0 in main () at x.c:4
(gdb)
The interesting thread is the one marked with an asterisk in the threads listing. See the section
about gdb(1) on how to read the stacktrace.
If frame #0 shows an address in user written code (the executable or a shared library provided
with it), it is most probably a programming problem of the vendor, and then he is the one who
has to fix this problem. However, it still could be that the problem is caused by a system runtime
library, e.g. if a function call from a runtime library returned illegal data which lead to the abort
in the user code.
If frame #0 shows an address in a system library, it must be checked what parameters had been
passed to the library call, and if they were valid. Most of the time, passing invalid parameters to
system function calls is the reason why applications abort.
If it turns out, or at least if it seems to be a problem with an HP provided runtime library, it is
always helpful to get the program vendor to provide source code of a little test case that shows
the problem. This will make the analysis of the problem much easier for HP support, expert
center or the labs.
Out Of Memory
Often it is said that a program crashed because it could not allocate memory. This is many times
not true. It is pretty common for an application to abort because it didn't realize that an allocation
(malloc, brk, shmget, etc) returned an error code. It then tried to access a memory region that
was not allocated (normally a null pointer returned by the faulting call) and received a signal
(SIGBUS, SIGSEGV) instead. A well designed program will check the return code and handle the
situation properly, e.g. by exiting with an error message.
The problem with such aborts is that they happen only when accessing the invalid address, not
when the allocation failure occurred, so usually at the first glance it cannot be said if the program
ran out of memory, or if the crash had a different reason.
To find out, we need to check the used process address space against the system limits and find
the type of memory that was exhausted, if any. The solution then is to either provide more
resources, or make the program use less.
Three system calls provide different types of memory to a process: