stack growth failure

[E. Brown]

Hi all

I received the following error while running a particularly long test script on a C3000 machine running HP-UX 11i V1.

Pid 19278 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Test script exited ok.

maxsiz for the machine is 8388608.

The error message gives several possible reasons for the failure. As such is it possible to monitor the following while running the process?
Memory
Swap space
Stack size

Thanks for any help you can give.

Ed

[A. Clay Stephenson · Accepted solution]

Trust the error message. Insufficient (physical) memory will not cause this although insufficient virtual memory could -- meaning additional swap might be needed. However, 8MiB is the default stack size and that is often a bit too small. Increase maxssiz to 32MiB or in an extreme case to 64MiB. Even in extreme cases for 64-bit code does maxssiz_64bit ever need to be larger than about 128MiB.

I would go ahead and increase to 32MiB. Very seldom does well-written code ever need a larger stack than that. If you still get stack overflows then you probably have very deep recursion and that is likely to be a data-related problem (or simply bad code).

It's not easy to monitor stack usage on a running process although you can run swapinfo while a process is running. It's pointless to worry about running out of memory because HP-UX is a virtual memory system rather than a physical memory system so when your swap space is entirely filled then you have failures.

[Tim Nelson]

Try to increase maxssiz and/or maxssiz_64bit

You would have to send some system information to have input for the other items.

How much memory is in the system ?
How much swap is configured ?
If the system has only xGB then trying to run a program with a stack of over xGB probably will not work.

[Dennis Handly]

>The error message gives several possible reasons for the failure.

The most common one (#4) is a programming error with recursive stack overflow. If you have a core file, you can use gdb to check this out with the "bt" command.

And if you increase maxssiz, it will just take longer to abort.

There are cases where you need such a large stack, some Fortran applications allocate big arrays there.

>Clay: It's not easy to monitor stack usage on a running process

You can use glance or attach with gdb.
Or you could write a program using pstat(2) to look at memory regions for processes.

[whiteknight]

Ed,

stack growth failure":

The program tried to access an address in the memory reserved for stack as
defined by the maxssiz or maxssiz_64bit kernel parameters and
the kernel was unable to find sufficient memory to do this or the address was
located in some guard pages surrounding this area. The test_stackgrowth
program shows this by calling a recursive function until all the stack space
has been used and the program hits a guard page.

This error is fatal for a process and no signal handler will be called as a
result even if one for SIGSEGV is installed.

Check if your program is 64bit or 32bit
WK

[Dennis Handly]

>WK: no signal handler will be called as a result even if one for SIGSEGV is installed.

You are confused. :-) After decades of believing this, you have to read the fine print and there you will discover that you need to use sigaltstack(2).