<?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: stack growth failure in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115030#M726770</link>
    <description>Ed,&lt;BR /&gt;&lt;BR /&gt;stack growth failure": &lt;BR /&gt;&lt;BR /&gt;The program tried to access an address in the memory reserved for stack as &lt;BR /&gt;defined by the maxssiz or maxssiz_64bit kernel parameters and &lt;BR /&gt;the kernel was unable to find sufficient memory to do this or the address was &lt;BR /&gt;located in some guard pages surrounding this area. The test_stackgrowth &lt;BR /&gt;program shows this by calling a recursive function until all the stack space &lt;BR /&gt;has been used and the program hits a guard page. &lt;BR /&gt;&lt;BR /&gt;This error is fatal for a process and no signal handler will be called as a &lt;BR /&gt;result even if one for SIGSEGV is installed. &lt;BR /&gt;&lt;BR /&gt;Check if your program is 64bit or 32bit&lt;BR /&gt;WK</description>
    <pubDate>Wed, 12 Dec 2007 02:15:49 GMT</pubDate>
    <dc:creator>whiteknight</dc:creator>
    <dc:date>2007-12-12T02:15:49Z</dc:date>
    <item>
      <title>stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115026#M726766</link>
      <description>Hi all&lt;BR /&gt;&lt;BR /&gt;I received the following error while running a particularly long test script on a C3000 machine running HP-UX 11i V1.&lt;BR /&gt;&lt;BR /&gt;Pid 19278 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;Test script exited ok.&lt;BR /&gt;&lt;BR /&gt;maxsiz for the machine is 8388608.&lt;BR /&gt;&lt;BR /&gt;The error message gives several possible reasons for the failure. As such is it possible to monitor the following while running the process?&lt;BR /&gt;Memory&lt;BR /&gt;Swap space&lt;BR /&gt;Stack size &lt;BR /&gt;&lt;BR /&gt;Thanks for any help you can give.&lt;BR /&gt;&lt;BR /&gt;Ed&lt;BR /&gt;</description>
      <pubDate>Tue, 11 Dec 2007 17:13:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115026#M726766</guid>
      <dc:creator>E. Brown</dc:creator>
      <dc:date>2007-12-11T17:13:41Z</dc:date>
    </item>
    <item>
      <title>Re: stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115027#M726767</link>
      <description>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. &lt;BR /&gt;&lt;BR /&gt;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).&lt;BR /&gt;&lt;BR /&gt;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.</description>
      <pubDate>Tue, 11 Dec 2007 17:36:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115027#M726767</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2007-12-11T17:36:01Z</dc:date>
    </item>
    <item>
      <title>Re: stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115028#M726768</link>
      <description>Try to increase maxssiz and/or maxssiz_64bit &lt;BR /&gt;&lt;BR /&gt;You would have to send some system information to have input for the other items.&lt;BR /&gt;&lt;BR /&gt;How much memory is in the system ?&lt;BR /&gt;How much swap is configured ?&lt;BR /&gt;If the system has only xGB then trying to run a program with a stack of over xGB probably will not work.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 11 Dec 2007 17:38:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115028#M726768</guid>
      <dc:creator>Tim Nelson</dc:creator>
      <dc:date>2007-12-11T17:38:35Z</dc:date>
    </item>
    <item>
      <title>Re: stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115029#M726769</link>
      <description>&amp;gt;The error message gives several possible reasons for the failure. &lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;And if you increase maxssiz, it will just take longer to abort.&lt;BR /&gt;&lt;BR /&gt;There are cases where you need such a large stack, some Fortran applications allocate big arrays there.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;Clay: It's not easy to monitor stack usage on a running process &lt;BR /&gt;&lt;BR /&gt;You can use glance or attach with gdb.&lt;BR /&gt;Or you could write a program using pstat(2) to look at memory regions for processes.</description>
      <pubDate>Wed, 12 Dec 2007 02:06:05 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115029#M726769</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2007-12-12T02:06:05Z</dc:date>
    </item>
    <item>
      <title>Re: stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115030#M726770</link>
      <description>Ed,&lt;BR /&gt;&lt;BR /&gt;stack growth failure": &lt;BR /&gt;&lt;BR /&gt;The program tried to access an address in the memory reserved for stack as &lt;BR /&gt;defined by the maxssiz or maxssiz_64bit kernel parameters and &lt;BR /&gt;the kernel was unable to find sufficient memory to do this or the address was &lt;BR /&gt;located in some guard pages surrounding this area. The test_stackgrowth &lt;BR /&gt;program shows this by calling a recursive function until all the stack space &lt;BR /&gt;has been used and the program hits a guard page. &lt;BR /&gt;&lt;BR /&gt;This error is fatal for a process and no signal handler will be called as a &lt;BR /&gt;result even if one for SIGSEGV is installed. &lt;BR /&gt;&lt;BR /&gt;Check if your program is 64bit or 32bit&lt;BR /&gt;WK</description>
      <pubDate>Wed, 12 Dec 2007 02:15:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115030#M726770</guid>
      <dc:creator>whiteknight</dc:creator>
      <dc:date>2007-12-12T02:15:49Z</dc:date>
    </item>
    <item>
      <title>Re: stack growth failure</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115031#M726771</link>
      <description>&amp;gt;WK: no signal handler will be called as a result even if one for SIGSEGV is installed. &lt;BR /&gt;&lt;BR /&gt;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).</description>
      <pubDate>Wed, 12 Dec 2007 02:57:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-growth-failure/m-p/4115031#M726771</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2007-12-12T02:57:48Z</dc:date>
    </item>
  </channel>
</rss>

