received a SIGSEGV for stack growth failure. Possible causes: insufficient memory or swap space

[vijay_57]

hi,

Iam trying to compile ACE5.4.1, latest release on my HP-UX 11.23 machine, i get the following compile error,

Pid 6265 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
/bin/sh: 6265 Memory fault(coredump)
make: *** [cppinset.cpp] Error 139


Here is system info
HP-UX B.11.23 U ia64 unlimited-user license


# swapinfo -tm
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 49 4047 1% 0 - 1 /dev/vg00/lvol2
localfs 35746 0 35746 0% 35746 0 1 /chunk1/paging
localfs 40 0 40 0% 40 10 2 /chunk2/paging
reserve - 380 -380
memory 2037 869 1168 43%
total 41919 1298 40621 3% - 10 -


# kctune | grep swap
allocate_fs_swapmap 0 Default
dmp_swapdev_is_vol 0 Default
nswapdev 10 Default
nswapfs 10 Default
remote_nfs_swap 0 Default
swapmem_on 1 1
vol_swapdev_is_vol 0 Default



# sysdef | grep max
dbc_max_pct 50 - - -
maxdsiz 107520 - 0-655360 Pages -
maxdsiz_64bit 1048576 - 256-1048576 Pages -
maxfiles 2048 - 30-2048 -
maxfiles_lim 4096 - 30-2048 -
maxssiz 98048 - 0-655360 Pages -
maxssiz_64bit 262144 - 256-1048576 Pages -
maxswapchunks 0 - 1-16384 -
maxtsiz 81920 - 0-655360 Pages -
maxtsiz_64bit 262144 - 256-1048576 Pages -
maxuprc 256 - 3- -
maxvgs 10 - - -


In particular, i get the error when compiling
$ACE_ROOT/apps/gperf/tests/Makefile

I tried changing maxssiz, maxdsiz & maxtsiz through "kctune" and "SAM"

I also made change in swapspace, still i get the error,


Can this be resolved by any patch?

Thanks in advance.,

[RAC_1]

Compare the output of (stack)
ulimit -Sa

with kernel tunable maxssiz and maxssiz_64bit.

Anil If your application is 64 bit, you should be looking at maxssiz_64bit.

Try setting stack to the value os maxssiz.
ulimit -s "stack_value"

Anil

[Steven E. Protter]

can you post output from:

swapinfo -tam

Also, you might want to collect performance data so you know what to play with. The rec's in the prior post are critical and should be acted upon immediately.

See attached script.

SEP

[Rita C Workman]

First fix the obvious....dbc_max_pct !!

50% is default .... so you are taking 50% off the top. The most you need is about 300-350Mb.
Drop it to 9 or 10 and put the dbc_min at maybe 4 or 5....

Rita

[Rita C Workman]

Am I reading this right....
maxfile = 2048 .... ok
maxswapchunks = 0 ..... huh..

maxswapchunks should be set to the limit 16384, otherwise you totally defeat the purpose of extending swapspace on the fly.
So let's look at this. Total swap that can be configured is maxswapchunks * swapchunk.
See my point....what is 0 x 2048 !!

Go back....fix dbc_max & min_pct. Do you have pseudoswap turned on ... maybe you should consider turning this on. And fix your parms that control the amount available swap.

Hope this helps...and hope I read your listings correctly.
Rgrds,
Rita

[Don Morris_1]

maxswapchunks SHOULD NOT BE THERE on 11.23 (or 11.22 for that matter). It is obsolete and gone.

Only swchunk matters for r11.22 and later. The kernel will self-adjust what maxswapchunks used to control as needed.

[Rita C Workman]

....well since I haven't switched any over to 11.23, I hadn't noticed that.

Thanks....just goes to show...we all need to keep up with reading the changes.

Rgrds,
Rita

[Don Morris_1]

Anyway... maxswapchunks aside... your swap certainly looks adaquate.

The first thing I'd try is (as mentioned above) to check the ulimit of the shell. maxssiz controls the stack default limit - but that can be overriden by a process to a lower value... and that lower value gets inherited by all children of that process. So if your login/profile script for your shell sets a low limit, every process you exec from the shell would share that low limit -- changing the kernel tunable wouldn't help.

If it isn't the ulimit, raise maxssiz and try again (maybe this thing just needs a big stack for some reason). The tunable is dynamic, so it won't hurt to raise it and lower it back if it doesn't work.

If that isn't it -- the only other thing that's coming to mind is to check unlockable_mem. If the process/thread is set to MCL_FUTURE (via mlockall) or is explicitly locking the stack you may not be failing the grow per se, the growth may just not be able to lock the new pages due to insufficient lockable memory.

If that isn't it either -- see if it left a core file and find out (from the core) just how big the stack segment was so we can hopefully get a better idea.