<?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 Overflow error in HPUX11iv2 in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-overflow-error-in-hpux11iv2/m-p/4610072#M376587</link>
    <description>Hi Jishi,&lt;BR /&gt;&lt;BR /&gt; you either have a main stack or a thread stack overflow.&lt;BR /&gt;You need to get a stack trace (use gdb) to determine which.&lt;BR /&gt;&lt;BR /&gt;On the WDB page you can find this document:&lt;BR /&gt;Debugging core files using HP WDB&lt;BR /&gt;&lt;A href="http://www.hp.com/go/wdb" target="_blank"&gt;http://www.hp.com/go/wdb&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Basically on the same system that caused the core dump:&lt;BR /&gt;$ file core&lt;BR /&gt;(Gives you the signal and up to 14 bytes of the basename of the executable.&lt;BR /&gt;&lt;BR /&gt;$ gdb path-to/executable core&lt;BR /&gt;(gdb) bt&lt;BR /&gt;(gdb) q&lt;BR /&gt;&lt;BR /&gt;If it is a main thread, you should see main at the bottom. If it is a thread, you should see some pthread on the bottom.&lt;BR /&gt;&lt;BR /&gt;By taking the difference in the $sp register from the top and bottom frames, you can compute your current stack size.&lt;BR /&gt;&lt;BR /&gt;There are two possibilities:&lt;BR /&gt;1) The user's shell (or a parent of that shell) has lowered the hard limit &lt;BR /&gt;using ulimit -h - at which point you have to find this and modify it. &lt;BR /&gt;Note, this is very rare -- you are much more likely to have to:&lt;BR /&gt;&lt;BR /&gt;2) The system-wide hard limit is determined by the kernel tunable "maxssiz" and/or "maxssiz_64bit". maxssiz is the limit for 32-bit processes, maxssiz_64bit for 64-bit. &lt;BR /&gt;Note that maxssiz_64bit trumps maxssiz_32bit (i.e. a lower 64-bit limit will be used instead of the 32-bit limit.. this is a consequence of the parent bitness as the system comes up), so you'll want to consider both.&lt;BR /&gt;&lt;BR /&gt;On 11.23, maxssiz / maxssiz_64bit are dynamic - changes to them take effect immediately for any new processes. So "kctune -u -s maxssiz=&lt;INSERT whatever="" value="" you="" actually="" need="" here=""&gt;" and that should do it.&lt;BR /&gt;&lt;BR /&gt;As a side note - if the user believes they need a very large stack, make sure that they understand why. Fortran and Java are both legitimate use cases -- for normal C programming, large stacks are usually a sign of poor recursion. Not saying there's a problem, but just worth a mention.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Cheers,&lt;BR /&gt;taifur&lt;/INSERT&gt;</description>
    <pubDate>Wed, 31 Mar 2010 03:59:06 GMT</pubDate>
    <dc:creator>Taifur</dc:creator>
    <dc:date>2010-03-31T03:59:06Z</dc:date>
    <item>
      <title>Stack Overflow error in HPUX11iv2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-overflow-error-in-hpux11iv2/m-p/4610071#M376586</link>
      <description>Hi All,&lt;BR /&gt;&lt;BR /&gt;Getting following error in Application while doing the EOD Operation. &lt;BR /&gt;failure in writing the signal contec-possible stack overflow. &lt;BR /&gt;sendsig: useracc failed.&lt;BR /&gt;&lt;BR /&gt;Can anybody help me in this issue? and how to increase the stack?&lt;BR /&gt;&lt;BR /&gt;Thanks &amp;amp; regards,&lt;BR /&gt; Sujeet Joshi&lt;BR /&gt;</description>
      <pubDate>Wed, 31 Mar 2010 01:53:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-overflow-error-in-hpux11iv2/m-p/4610071#M376586</guid>
      <dc:creator>sujeet joshi</dc:creator>
      <dc:date>2010-03-31T01:53:54Z</dc:date>
    </item>
    <item>
      <title>Re: Stack Overflow error in HPUX11iv2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-overflow-error-in-hpux11iv2/m-p/4610072#M376587</link>
      <description>Hi Jishi,&lt;BR /&gt;&lt;BR /&gt; you either have a main stack or a thread stack overflow.&lt;BR /&gt;You need to get a stack trace (use gdb) to determine which.&lt;BR /&gt;&lt;BR /&gt;On the WDB page you can find this document:&lt;BR /&gt;Debugging core files using HP WDB&lt;BR /&gt;&lt;A href="http://www.hp.com/go/wdb" target="_blank"&gt;http://www.hp.com/go/wdb&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Basically on the same system that caused the core dump:&lt;BR /&gt;$ file core&lt;BR /&gt;(Gives you the signal and up to 14 bytes of the basename of the executable.&lt;BR /&gt;&lt;BR /&gt;$ gdb path-to/executable core&lt;BR /&gt;(gdb) bt&lt;BR /&gt;(gdb) q&lt;BR /&gt;&lt;BR /&gt;If it is a main thread, you should see main at the bottom. If it is a thread, you should see some pthread on the bottom.&lt;BR /&gt;&lt;BR /&gt;By taking the difference in the $sp register from the top and bottom frames, you can compute your current stack size.&lt;BR /&gt;&lt;BR /&gt;There are two possibilities:&lt;BR /&gt;1) The user's shell (or a parent of that shell) has lowered the hard limit &lt;BR /&gt;using ulimit -h - at which point you have to find this and modify it. &lt;BR /&gt;Note, this is very rare -- you are much more likely to have to:&lt;BR /&gt;&lt;BR /&gt;2) The system-wide hard limit is determined by the kernel tunable "maxssiz" and/or "maxssiz_64bit". maxssiz is the limit for 32-bit processes, maxssiz_64bit for 64-bit. &lt;BR /&gt;Note that maxssiz_64bit trumps maxssiz_32bit (i.e. a lower 64-bit limit will be used instead of the 32-bit limit.. this is a consequence of the parent bitness as the system comes up), so you'll want to consider both.&lt;BR /&gt;&lt;BR /&gt;On 11.23, maxssiz / maxssiz_64bit are dynamic - changes to them take effect immediately for any new processes. So "kctune -u -s maxssiz=&lt;INSERT whatever="" value="" you="" actually="" need="" here=""&gt;" and that should do it.&lt;BR /&gt;&lt;BR /&gt;As a side note - if the user believes they need a very large stack, make sure that they understand why. Fortran and Java are both legitimate use cases -- for normal C programming, large stacks are usually a sign of poor recursion. Not saying there's a problem, but just worth a mention.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Cheers,&lt;BR /&gt;taifur&lt;/INSERT&gt;</description>
      <pubDate>Wed, 31 Mar 2010 03:59:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-overflow-error-in-hpux11iv2/m-p/4610072#M376587</guid>
      <dc:creator>Taifur</dc:creator>
      <dc:date>2010-03-31T03:59:06Z</dc:date>
    </item>
    <item>
      <title>Re: Stack Overflow error in HPUX11iv2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stack-overflow-error-in-hpux11iv2/m-p/4610073#M376588</link>
      <description>&amp;gt;Taifur: you either have a main stack or a thread stack overflow.  You need to get a stack trace (use gdb) to determine which.&lt;BR /&gt;&lt;BR /&gt;Exactly.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;So "kctune -u -s maxssiz=&lt;INSERT&gt;&lt;BR /&gt;&lt;BR /&gt;-u and -s are obsolete kmtune(1m) options.  You should leave both off.&lt;/INSERT&gt;</description>
      <pubDate>Wed, 31 Mar 2010 04:56:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stack-overflow-error-in-hpux11iv2/m-p/4610073#M376588</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2010-03-31T04:56:47Z</dc:date>
    </item>
  </channel>
</rss>

