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

HP-UX Handbook – Rev 13.00 Page 84 (of 101)
Chapter 11 Software Development
October 29, 2013
Stack Overflow
In the process memory section we learned that the stack holds a lot of important information for
the program flow. A stack overflow or corruption will normally cause the process to abort with a
signal and leave a core file, but debugging such a core file can become very hard, because the
debugger might not be able to recover the program flow information. In that case you cannot
even get a valid stacktrace from the core file.
At runtime you cannot see the stack grow with top(1) because it doesn't distinguish the type of
allocated memory. Also, you can't see stack growth with tusc(1) because no system calls are
involved when increasing the stack. To find out the current stack size of a running process is to
print out the value of its stack pointer using a debugger.
The stack starts at 0x80000000-(maxdsiz+0x1000) resp. 0xc0000000-(maxdsiz+0x1000) for
q3p/q4p programs, and ends at the end of the quadrant. The additional size of 0x1000 is due to
the 4k guard page, which is added automatically by the kernel. The guard page is a region
protected against both read and write accesses. When a program tries to access an address within
the guard page, it will be aborted with SIGBUS.
On PA-RISC the stack grows upwards, and the guard page is located at the end of the stack
region. The stack pointer $sp always points to the current upper end of the stack:
0x7ffff000
-maxdsiz
v
$sp
v
0x80000000
0x7ffff000 |
v v
Stack
==> unused *1
guard
Page
*1: reserved for the stack
A stack overflow occurs when $sp reaches the guard page. We can find out the value of $sp as
follows:
$ gdb –q myprog 7753
:
(gdb) p/x $sp
$1 = 0x7f7f0b10
(gdb) x/x 0x7fffff00 ### address in the middle of the guard page
0x7fffff00: Error accessing memory address 0x7fffff00: Bad address.
(gdb) q
Here we still have 0x80e4f0 (ca. 8 MB) Bytes available for further stack growth.