SIGSEGV for stack growth failure

[Srinivas Sreekumar]

Following error is received on running a C code :
Pid 13083 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
./migration.sh[147]: 13083 Memory fault(coredump)

Sysdef output is as below:
NAME VALUE BOOT MIN-MAX UNITS FLAGS
acctresume 4 - -100-100 -
acctsuspend 2 - -100-100 -
allocate_fs_swapmap 0 - - -
bufpages 308938 - 0- Pages -
create_fastlinks 0 - - -
dbc_max_pct 15 - - -
dbc_min_pct 2 - - -
default_disk_ir 0 - - -
dskless_node 0 - 0-1 -
eisa_io_estimate 768 - - -
eqmemsize 78 - - -
file_pad 10 - 0- -
fs_async 0 - 0-1 -
hpux_aes_override 0 - - -
maxdsiz 458752 - 0-503866 Pages -
maxdsiz_64bit 4194304 - 1024-1073479679 Pages -
maxfiles 5000 - 30-2048 -
maxfiles_lim 5000 - 30-2048 -
maxssiz 25600 - 0-98048 Pages -
maxssiz_64bit 262144 - 4-262144 Pages -
maxswapchunks 12000 - 1-16384 -
maxtsiz 262144 - 0-503859 Pages -
maxtsiz_64bit 262144 - 1024-1073741823 Pages -
maxuprc 7372 - 3- -
maxvgs 30 - - -
msgmap 32759 - 3- -
nbuf 153816 - 0- -
ncallout 8208 - 6- -
ncdnode 150 - - -
ndilbuffers 30 - 1- -
netisr_priority -1 - -1-127 -
netmemmax 0 - - -
nfile 124938 - 14- -
nflocks 16384 - 2- -
ninode 67584 - 14- -
no_lvm_disks 0 - - -
nproc 8192 - 10- -
npty 2048 - 1- -
nstrpty 2048 - - -
nswapdev 25 - 1-25 -
nswapfs 10 - 1-25 -
public_shlibs 1 - - -
remote_nfs_swap 0 - - -
rtsched_numpri 32 - - -
sema 0 - 0-1 -
semmap 16383 - 4- -
shmem 0 - 0-1 -
shmmni 1024 - 3-1024 -
streampipes 0 - 0- -
swapmem_on 1 - - -
swchunk 2048 - 2048-16384 kBytes -
timeslice 10 - -1-2147483648 Ticks -
unlockable_mem 32968 - 0- Pages -
***********************************************Total RAM : 16GB

Swapinfo (swapinfo -mt) :
dev 32768
reserve -
memory 13125
total 45893

Please let us know the cause of this error.

Thanks

[Ermin Borovac]

Most likely cause is that your process has exceeded size of the stack limits imposed by maxssiz (32-bit) or maxssiz_64bit (64-bit) kernel parameters. You will want to increase maxssiz/maxssiz_64bit (depending on whether your program is 32 or 64 bit), recompile the kernel and reboot.

Most of the time stack usage is attributed to use of large local variables/arrays in functions.

[Manish Srivastava]

Hi,

As told earlier you can increase the maxssiz but if that does not solve the problem you could look into the code for high looping or recursion.

does this code interact with any database?

manish

[Muthukumar_5]

You have to check stack size there.

ulimit -s

and kernel parameters of
maxssiz 25600 - 0-98048 Pages -
maxssiz_64bit 262144 - 4-262144 Pages -

and swap size will not be a problem there.

Another point is to check core file as,

what core
file core
gdb
gdb> bt

will give informations there.

[Srinivas Sreekumar]

Thanks for the replies.
ulimit -s does'nt work on out HP UX 11.11 server, gives the below error
ksh: ulimit: bad option(s)

[Muthukumar_5]

Can you try as,

ulimit -a

It will give every user limitation informations there.

ulimit -Hs --> Hard limit
ulimit -Ss --> Soft limit

I have tried on 11.11 too. No problem there. Try with hard / soft limit(s) there.

HTH.

[Ermin Borovac]

ulimit is shell built-in command. 'ulimit -s' should work with posix shell (/usr/bin/sh) and korn shell (/usr/bin/ksh) starting with PHCO_27019 (ksh patch). You seem to be using korn shell, but probably don't have PHCO_27019 installed.

'ulimit -s' is limited by maxssiz anyway, so in posix shell it would show you 25600 (25M).

If you have glance you can verify that stack overflow is a problem by selecting a process (press s then type PID of the C program), then press F3 to go to memory regions screen. Then you can watch Stack RSS/VSS value. If it goes close to 25M then you should increase maxssiz.

I would increase maxssiz to maybe 64M (100M at most). If this still doesn't help then you should look at your C program and make some modifications to use malloc() in favour of large local arrays. This would make the program allocate memory from heap instead of stack.

[Bill Hassell]

ulimit -s (and ulimit -a to list all env parameters) works just fine on ksh if you are up to date on patches. ksh only recently added ulimit options. That's one of the many reasons to use the POSIX shell (/usr/bin/sh) rather than ksh. Note that sh is NOT the Bourne shell like most other flavors of Unix.

To find out if your program is 64bit, use the file command as in:

file your_program

If the word ELF is not reported back, your program is a simple 32bit program and subject to severe addressing limitations, basically you maximum data area is only 960 megs (or less if maxdsiz is less than 960megs)