SIGSEGV for stack growth failure

[hpinvent_1]

Hi,
I'm getting the following error while trying to collect logs.
"Pid 21672 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz."

I've attached the swapinfo and kmtune output below. It would be great if any of you could help me in getting a workaround.
Regards,
Daniel

# swapinfo -t
Kb Kb Kb PCT START/ Kb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 2097152 0 2097152 0% 0 - 1 /dev/vg00/lvol2
reserve - 226892 -226892
memory 734548 292120 442428 40%
total 2831700 519012 2312688 18% - 0 -

kmtune output
-------------
dbc_max_pct 7 - 7
dbc_min_pct 5 - 5
max_thread_proc 1100 - 1100
maxdsiz 1073741824 - 1073741824
maxdsiz_64bit 2147483648 - 2147483648
maxfiles 60 - 60
maxfiles_lim 1024 Y 1024
maxqueuetime - - 0
maxssiz 134217728 - 134217728
maxssiz_64bit 1073741824 - 1073741824
maxswapchunks 16384 - 16384
maxtsiz 0x4000000 Y 0X4000000
maxtsiz_64bit 0x40000000 Y 0X40000000
maxuprc 3686 Y 3686
maxusers 32 - 32
maxvgs 10 - 10
mesg 1 - 1
nproc 4096 - 4096
sema 1 - 1
semaem 16384 - 16384
semmap 4098 - 4098
semmni 4096 - 4096
semmns 8192 - 8192
semmnu 4092 - 4092
semmsl 2048 Y 2048
semume 10 - 10
semvmx 32768 - 32768
sendfile_max 0 - 0
shmem 1 - 1
shmmax 790151168 Y 790151168
shmmni 512 - 512
shmseg 32 Y 32
vps_ceiling 64 - 64
vps_chatr_ceiling 1048576 - 1048576
vps_pagesize 4 - 4

[Don Morris_1]

Well, one would think 128Mb would be enough.
And unless you took the swapinfo output when the system was rather quiet and the log gathering is done under heavy load, you should have enough swap...

Which makes the big question -- just what are you trying to run? Is it a C program? Shell script? The first thing that comes to my mind is to check for one of two things:

1) If the failing program is a compiled binary and you have the source, look for big local declarations within functions (i.e. like struct foo A[1024*1024*1024]... if foo >=128 bytes, that would eat the whole stack).

2) In either event (program or script) - is there a lot of recursion (functions calling themselves) going on... This is my suspicion - perhaps you have a function which operates on each directory and calls itself for subdirectories... if the coder did not properly write the termination case you could be over-recursing, eating stack frames.

In either event - I think checking the code is what's needed here. You could try just raising maxssiz and hoping it works -- but I think without understanding just what the issue is you're just doing guesswork.

[Jeff Schussele · Accepted solution]

Well, we really don't have enough info to determine just what the cause is. BUT if I *had* to wager, I'd bet it's memory or swap.
It appears you have swapmem_on set so that leads me to believe you *only* have 1GB of RAM in this system. That's fairly small for any significant SW like a DB or intense Java app.
And then we also need to know whether the SW you're running is 64 bit or 32.
As stated we really need to see the swapinfo -tam output at the time you get the error.

Rgds,
Jeff

[hpinvent_1]

Thanks a lot for the replies Jeff Schussele and Don Morris. It gave me good information about the hardware constraints. I'm trying to run Oracle 9i Parallel Server on a two node cluster. The Kernel parameters and swapinfo apply for both machines. Both are L Class machines but they have only 1GB RAM. I'll send the swapinfo -tam in my next mail. Could any of you please tell me the Physical memory requirements for running Oracle 9i Parallel Server? I'd like to know the minimum RAM size.
Thanks and Regards,
Daniel

[hpinvent_1]

I've attached the swapinfo -tam for both the cluster nodes

# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 2048 0 2048 0% 0 - 1 /dev/vg00/lvol2
dev 1000 0 1000 0% 0 - 2 /dev/vg00/lvol9
reserve - 215 -215
memory 717 232 485 32%
total 3765 447 3318 12% - 0 -
#

# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 2048 0 2048 0% 0 - 1 /dev/vg00/lvol2
reserve - 213 -213
memory 717 278 439 39%
total 2765 491 2274 18% - 0 -
#