<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: SIGSEGV for stack growth failure in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285805#M882680</link>
    <description>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.&lt;BR /&gt;Thanks and Regards,&lt;BR /&gt;Daniel</description>
    <pubDate>Wed, 26 May 2004 01:57:23 GMT</pubDate>
    <dc:creator>hpinvent_1</dc:creator>
    <dc:date>2004-05-26T01:57:23Z</dc:date>
    <item>
      <title>SIGSEGV for stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285802#M882677</link>
      <description>Hi,&lt;BR /&gt;I'm getting the following error while trying to collect logs.&lt;BR /&gt;"Pid 21672 received a SIGSEGV for stack growth failure.&lt;BR /&gt;Possible causes: insufficient memory or swap space,&lt;BR /&gt;or stack size exceeded maxssiz."&lt;BR /&gt;&lt;BR /&gt;I've attached the swapinfo and kmtune output below. It would be great if any of you could help me in getting a workaround. &lt;BR /&gt;Regards,&lt;BR /&gt;Daniel&lt;BR /&gt;&lt;BR /&gt;# swapinfo -t&lt;BR /&gt;             Kb      Kb      Kb   PCT  START/      Kb&lt;BR /&gt;TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME&lt;BR /&gt;dev     2097152       0 2097152    0%       0       -    1  /dev/vg00/lvol2&lt;BR /&gt;reserve       -  226892 -226892&lt;BR /&gt;memory   734548  292120  442428   40%&lt;BR /&gt;total   2831700  519012 2312688   18%       -       0    -&lt;BR /&gt;&lt;BR /&gt;kmtune output&lt;BR /&gt;-------------&lt;BR /&gt;dbc_max_pct                 7  -  7&lt;BR /&gt;dbc_min_pct                 5  -  5&lt;BR /&gt;max_thread_proc          1100  -  1100&lt;BR /&gt;maxdsiz            1073741824  -  1073741824&lt;BR /&gt;maxdsiz_64bit      2147483648  -  2147483648&lt;BR /&gt;maxfiles                   60  -  60&lt;BR /&gt;maxfiles_lim             1024  Y  1024&lt;BR /&gt;maxqueuetime                -  -  0&lt;BR /&gt;maxssiz             134217728  -  134217728&lt;BR /&gt;maxssiz_64bit      1073741824  -  1073741824&lt;BR /&gt;maxswapchunks           16384  -  16384&lt;BR /&gt;maxtsiz             0x4000000  Y  0X4000000&lt;BR /&gt;maxtsiz_64bit      0x40000000  Y  0X40000000&lt;BR /&gt;maxuprc                  3686  Y  3686&lt;BR /&gt;maxusers                   32  -  32&lt;BR /&gt;maxvgs                     10  -  10&lt;BR /&gt;mesg                        1  -  1&lt;BR /&gt;nproc                    4096  -  4096&lt;BR /&gt;sema                        1  -  1&lt;BR /&gt;semaem                  16384  -  16384&lt;BR /&gt;semmap                   4098  -  4098&lt;BR /&gt;semmni                   4096  -  4096&lt;BR /&gt;semmns                   8192  -  8192&lt;BR /&gt;semmnu                   4092  -  4092&lt;BR /&gt;semmsl                   2048  Y  2048&lt;BR /&gt;semume                     10  -  10&lt;BR /&gt;semvmx                  32768  -  32768&lt;BR /&gt;sendfile_max                0  -  0&lt;BR /&gt;shmem                       1  -  1&lt;BR /&gt;shmmax              790151168  Y  790151168&lt;BR /&gt;shmmni                    512  -  512&lt;BR /&gt;shmseg                     32  Y  32&lt;BR /&gt;vps_ceiling                64  -  64&lt;BR /&gt;vps_chatr_ceiling     1048576  -  1048576&lt;BR /&gt;vps_pagesize                4  -  4&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 25 May 2004 04:41:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285802#M882677</guid>
      <dc:creator>hpinvent_1</dc:creator>
      <dc:date>2004-05-25T04:41:44Z</dc:date>
    </item>
    <item>
      <title>Re: SIGSEGV for stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285803#M882678</link>
      <description>Well, one would think 128Mb would be enough.&lt;BR /&gt;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...&lt;BR /&gt;&lt;BR /&gt;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: &lt;BR /&gt;&lt;BR /&gt;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 &amp;gt;=128 bytes, that would eat the whole stack).&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.</description>
      <pubDate>Tue, 25 May 2004 09:44:15 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285803#M882678</guid>
      <dc:creator>Don Morris_1</dc:creator>
      <dc:date>2004-05-25T09:44:15Z</dc:date>
    </item>
    <item>
      <title>Re: SIGSEGV for stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285804#M882679</link>
      <description>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.&lt;BR /&gt;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.&lt;BR /&gt;And then we also need to know whether the SW you're running is 64 bit or 32.&lt;BR /&gt;As stated we really need to see the swapinfo -tam output at the time you get the error.&lt;BR /&gt;&lt;BR /&gt;Rgds,&lt;BR /&gt;Jeff</description>
      <pubDate>Tue, 25 May 2004 09:55:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285804#M882679</guid>
      <dc:creator>Jeff Schussele</dc:creator>
      <dc:date>2004-05-25T09:55:37Z</dc:date>
    </item>
    <item>
      <title>Re: SIGSEGV for stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285805#M882680</link>
      <description>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.&lt;BR /&gt;Thanks and Regards,&lt;BR /&gt;Daniel</description>
      <pubDate>Wed, 26 May 2004 01:57:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285805#M882680</guid>
      <dc:creator>hpinvent_1</dc:creator>
      <dc:date>2004-05-26T01:57:23Z</dc:date>
    </item>
    <item>
      <title>Re: SIGSEGV for stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285806#M882681</link>
      <description>I've attached the swapinfo -tam for both the cluster nodes&lt;BR /&gt;&lt;BR /&gt;# swapinfo -tam&lt;BR /&gt;             Mb      Mb      Mb   PCT  START/      Mb&lt;BR /&gt;TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME&lt;BR /&gt;dev        2048       0    2048    0%       0       -    1  /dev/vg00/lvol2&lt;BR /&gt;dev        1000       0    1000    0%       0       -    2  /dev/vg00/lvol9&lt;BR /&gt;reserve       -     215    -215&lt;BR /&gt;memory      717     232     485   32%&lt;BR /&gt;total      3765     447    3318   12%       -       0    -&lt;BR /&gt;#&lt;BR /&gt;&lt;BR /&gt;# swapinfo -tam&lt;BR /&gt;             Mb      Mb      Mb   PCT  START/      Mb&lt;BR /&gt;TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME&lt;BR /&gt;dev        2048       0    2048    0%       0       -    1  /dev/vg00/lvol2&lt;BR /&gt;reserve       -     213    -213&lt;BR /&gt;memory      717     278     439   39%&lt;BR /&gt;total      2765     491    2274   18%       -       0    -&lt;BR /&gt;#&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 26 May 2004 03:05:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sigsegv-for-stack-growth-failure/m-p/3285806#M882681</guid>
      <dc:creator>hpinvent_1</dc:creator>
      <dc:date>2004-05-26T03:05:57Z</dc:date>
    </item>
  </channel>
</rss>

