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

HP-UX Handbook – Rev 13.00 Page 87 (of 101)
Chapter 11 Software Development
October 29, 2013
MMF: b = 7360B000 e = 7368C000 f = 9B7A0C4
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
MMF: b = 7368C000 e = 7370D000 f = 9BFB0D4
:
$
In the above case the stack pointer is close to the start of the highlighted MMF region, that
means only a tiny bit of the thread stack was used and we were far away from a stack overflow.
If the stack pointer is near the end of the region, remember that the last 4k belong to the guard
page and the real end of the stack is 4k earlier than the end of the region.
On Itanium, both $sp and $bsp need to be checked. Since the guard page lies in the middle of
the thread stack, there might have been a problem if one of the registers reached the middle of
the thread stack region.
Stack overflows can be caused by infinite or too deep recursions, or by big local variables. If
increasing maxssiz or the thread stacksize to a reasonable value doesn’t help, the programmers
may need to change the code, e.g. by allocating large local variables dynamically with
malloc(3C). Fortran programmers can use the +save compiler option for that.
Heap Corruption
An abort under malloc() or any other heap allocation related function indicates a heap
corruption, e.g.:
#0 0xc0185588 in mallinfo+0xec8 () from /usr/lib/libc.2
#1 0xc0182c30 in __thread_callback_np+0x4f0 () from /usr/lib/libc.2
#2 0xc01888b0 in malloc+0x198 () from /usr/lib/libc.2
#3 0x294c in main+0x2c ()
Heap corruption means that data structures that are required to manage the heap contents, and
which are part of the heap, have been overwritten. Most of the time this is NOT bug in libc, but
rather a defect in the program, as we will see further down in this section.
The process heap is organized in kind of a linked list of blocks. For every allocated block,
malloc() stores a so called malloc header right before the block, which contains among other
things the length of the block, and a flag that indicates if the block is currently used by the
program or is free for reallocation. Right after the allocated block resides the malloc header for
the next block.
If a program writes beyond the end of an allocated block, this is called a buffer overrun. If it
writes beyond the beginning, this is a buffer underrun. Both will result in overwriting a malloc
header, thus corrupting the heap structures. Another cause could be writing to a block that has
already been freed (returned to the malloc pool for reuse).