<?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: Heap corruption? in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161855#M684632</link>
    <description>As you said, you have heap corruption if you abort after you call malloc/free.&lt;BR /&gt;Frames #0 and #1 with the bogus names are static functions used in with malloc.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;The problem seems to be occurring somewhere inside libc!&lt;BR /&gt;&lt;BR /&gt;libc is just the victim here.  You have likely corrupted the heap and gethostbyname was the first one to step in it.&lt;BR /&gt;&lt;BR /&gt;You need to get the latest WDB and use the heap checking options to see where the heap is first corrupted:&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;Under the documentation link there is a PDF of:&lt;BR /&gt;Debugging dynamic memory usage errors using HP WDB</description>
    <pubDate>Fri, 06 Mar 2009 21:13:24 GMT</pubDate>
    <dc:creator>Dennis Handly</dc:creator>
    <dc:date>2009-03-06T21:13:24Z</dc:date>
    <item>
      <title>Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161854#M684631</link>
      <description>Hello,&lt;BR /&gt;I'm trying to understand what's going wrong with a program run in HP-UX 11.11 that results in a SIGSEGV (11, segmentation fault):&lt;BR /&gt;&lt;BR /&gt;    (gdb) bt&lt;BR /&gt;    #0  0x737390e8 in _sigfillset+0x618 () from /usr/lib/libc.2&lt;BR /&gt;    #1  0x73736a8c in _sscanf+0x55c () from /usr/lib/libc.2&lt;BR /&gt;    #2  0x7373c23c in malloc+0x18c () from /usr/lib/libc.2&lt;BR /&gt;    #3  0x7379e3f8 in _findbuf+0x138 () from /usr/lib/libc.2&lt;BR /&gt;    #4  0x7379c9f4 in _filbuf+0x34 () from /usr/lib/libc.2&lt;BR /&gt;    #5  0x7379c604 in __fgets_unlocked+0x84 () from /usr/lib/libc.2&lt;BR /&gt;    #6  0x7379c7fc in fgets+0xbc () from /usr/lib/libc.2&lt;BR /&gt;    #7  0x7378ecec in __nsw_getoneconfig+0xf4 () from /usr/lib/libc.2&lt;BR /&gt;    #8  0x7378f8b8 in __nsw_getconfig+0x150 () from /usr/lib/libc.2&lt;BR /&gt;    #9  0x737903a8 in __thread_cond_init_default+0x100 () from /usr/lib/libc.2&lt;BR /&gt;    #10 0x737909a0 in nss_search+0x80 () from /usr/lib/libc.2&lt;BR /&gt;    #11 0x736e7320 in __gethostbyname_r+0x140 () from /usr/lib/libc.2&lt;BR /&gt;    #12 0x736e74bc in gethostbyname+0x94 () from /usr/lib/libc.2&lt;BR /&gt;    #13 0x11780 in dnetResolveName (name=0x400080d8 "smtp.org.com", hent=0x737f3334) at src/dnet.c:64&lt;BR /&gt;    ..&lt;BR /&gt;&lt;BR /&gt;The problem seems to be occurring somewhere inside libc! A system call trace ends with: &lt;BR /&gt;&lt;BR /&gt;    Connecting to server smtp.org.com on port 25&lt;BR /&gt;    write(1, "C o n n e c t i n g   t o   s e ".., 51) .......................... = 51&lt;BR /&gt;    open("/etc/nsswitch.conf", O_RDONLY, 0666) ............................... [entry]&lt;BR /&gt;    open("/etc/nsswitch.conf", O_RDONLY, 0666) ................................... = 5&lt;BR /&gt;      Received signal 11, SIGSEGV, in user mode, [SIG_DFL], partial siginfo&lt;BR /&gt;        Siginfo: si_code: I_NONEXIST, faulting address: 0x400118fc, si_errno: 0&lt;BR /&gt;        PC: 0xc01980eb, instruction: 0x0d3f1280&lt;BR /&gt;    exit(11) [implicit] ............................ WIFSIGNALED(SIGSEGV)|WCOREDUMP&lt;BR /&gt;&lt;BR /&gt;Last instruction by the program:&lt;BR /&gt;&lt;BR /&gt;    struct hostent *him;&lt;BR /&gt;    him = gethostbyname(name); // name == "smtp.org.com" as shown by gdb&lt;BR /&gt;&lt;BR /&gt;Is this a problem with the system, or am I missing something?&lt;BR /&gt;Any guidance for digging deeper would be appreciated.&lt;BR /&gt;&lt;BR /&gt;Thx.&lt;BR /&gt;</description>
      <pubDate>Fri, 06 Mar 2009 18:09:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161854#M684631</guid>
      <dc:creator>Sam20</dc:creator>
      <dc:date>2009-03-06T18:09:52Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161855#M684632</link>
      <description>As you said, you have heap corruption if you abort after you call malloc/free.&lt;BR /&gt;Frames #0 and #1 with the bogus names are static functions used in with malloc.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;The problem seems to be occurring somewhere inside libc!&lt;BR /&gt;&lt;BR /&gt;libc is just the victim here.  You have likely corrupted the heap and gethostbyname was the first one to step in it.&lt;BR /&gt;&lt;BR /&gt;You need to get the latest WDB and use the heap checking options to see where the heap is first corrupted:&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;Under the documentation link there is a PDF of:&lt;BR /&gt;Debugging dynamic memory usage errors using HP WDB</description>
      <pubDate>Fri, 06 Mar 2009 21:13:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161855#M684632</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2009-03-06T21:13:24Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161856#M684633</link>
      <description>I already have WDB.&lt;BR /&gt;How can I use it to track the heap corruption event?&lt;BR /&gt;Turning heap-check on, info heap only displays a list of allocations.. what can I do with that?&lt;BR /&gt;&lt;BR /&gt;Thank you for your help.</description>
      <pubDate>Mon, 09 Mar 2009 12:55:14 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161856#M684633</guid>
      <dc:creator>Sam20</dc:creator>
      <dc:date>2009-03-09T12:55:14Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161857#M684634</link>
      <description>&amp;gt;I already have WDB.&lt;BR /&gt;&lt;BR /&gt;Make sure you download the latest.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;How can I use it to track the heap corruption event?  Turning heap-check on&lt;BR /&gt;&lt;BR /&gt;That should do it.  Try:&lt;BR /&gt;(gdb) set heap-check on&lt;BR /&gt;(gdb) set heap-check string on footer-size 8&lt;BR /&gt;&lt;BR /&gt;I'm not sure if "info corruption" works on 11.11?</description>
      <pubDate>Tue, 10 Mar 2009 00:24:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161857#M684634</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2009-03-10T00:24:02Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161858#M684635</link>
      <description>&amp;gt;Make sure you download the latest.&lt;BR /&gt;Well, I didn't have the latest! I do now.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;(gdb) set heap-check on&lt;BR /&gt;&amp;gt;(gdb) set heap-check string on footer-size 8&lt;BR /&gt;&amp;gt;&lt;BR /&gt;&amp;gt;I'm not sure if "info corruption" works on &amp;gt;11.11?&lt;BR /&gt;&lt;BR /&gt;"info corruption" works. And it nailed it.&lt;BR /&gt;I executed the program step by step few instructions before the location where "bt" showed the SIGSEGV was born.&lt;BR /&gt;Slowing down and using "info corruption" every other instruction showed clearly that this one was the culprit:  &lt;BR /&gt;&lt;BR /&gt;226                     actualLen = vsnprintf(dsb-&amp;gt;str+dsb-&amp;gt;len, size, fmt, ap);&lt;BR /&gt;(gdb) info corruption&lt;BR /&gt;Analyzing heap ...&lt;BR /&gt;&lt;BR /&gt;No blocks were found.&lt;BR /&gt;&lt;BR /&gt;(gdb) n&lt;BR /&gt;229                     if (actualLen &amp;gt; -1 &amp;amp;&amp;amp; actualLen &amp;lt; size) {&lt;BR /&gt;(gdb) info corruption&lt;BR /&gt;Analyzing heap ...&lt;BR /&gt;&lt;BR /&gt;Following blocks appear to be corrupted&lt;BR /&gt;No.   Total bytes     Blocks     Corruption      Address        Function&lt;BR /&gt;0        5669647        1       End of block    0x4053f9b8 xrealloc()&lt;BR /&gt;(gdb) p size&lt;BR /&gt;$1 = 0&lt;BR /&gt;&lt;BR /&gt;vsnprintf is here called with 2nd arg == 0.&lt;BR /&gt;vsnprintf was introduced in C99 (ISO/IEC 9899:1999) and "is equivalent to snprintf, with the variable argument list" (Â§7.19.6.12.2), snprintf (Â§7.19.6.5.2): "If n is zero, nothing is written".&lt;BR /&gt;Well, HP UX 11.11 doesn't comply with this specification. Even though size == 0, arguments are written at the end of dsb-&amp;gt;str.. which, of course, corrupts the heap (no space is allocate when size==0, given that nothing should be written).&lt;BR /&gt;&lt;BR /&gt;HP manual pages are unclear ("It is the user's responsibility to ensure that enough storage is available." &lt;A href="http://docs.hp.com/en/B2355-90695/printf.3S.html)," target="_blank"&gt;http://docs.hp.com/en/B2355-90695/printf.3S.html),&lt;/A&gt; nothing is said regarding the case of maxsize==0. Nice trap.. at the very least, the WARNINGS section of the man page should warn std-compliant users..&lt;BR /&gt;&lt;BR /&gt;Anyway, workaround is trivial (never call v/snprintf under HP-UX with maxsize==0!) and I now have a stable running program!&lt;BR /&gt;&lt;BR /&gt;Thank you very much Dennis.&lt;BR /&gt;&lt;BR /&gt;--------------------------&lt;BR /&gt;Heap corruption through vsnprintf under HP-UX B11.11&lt;BR /&gt;This program prints "@@" under Linux/Cygwin/..&lt;BR /&gt;It prints "@fooo@" under HP-UX B11.11:&lt;BR /&gt;&lt;BR /&gt;#include &lt;STDARG.H&gt;&lt;BR /&gt;#include &lt;STDIO.H&gt;&lt;BR /&gt;&lt;BR /&gt;const int S=2;&lt;BR /&gt;&lt;BR /&gt;void f ( const char *fmt, ...) {&lt;BR /&gt;        va_list ap;&lt;BR /&gt;        int actualLen=0;&lt;BR /&gt;        char buf[S];&lt;BR /&gt;&lt;BR /&gt;        bzero( buf, S );&lt;BR /&gt;&lt;BR /&gt;        va_start( ap, fmt );&lt;BR /&gt;        actualLen = vsnprintf( buf, 0, fmt, ap );&lt;BR /&gt;        va_end( ap );&lt;BR /&gt;&lt;BR /&gt;        printf( "@%s@\n", buf );&lt;BR /&gt;}&lt;BR /&gt;&lt;BR /&gt;int main () {&lt;BR /&gt;        f( "%s", "fooo" );&lt;BR /&gt;        return 0;&lt;BR /&gt;}&lt;BR /&gt;&lt;BR /&gt;&lt;/STDIO.H&gt;&lt;/STDARG.H&gt;</description>
      <pubDate>Tue, 10 Mar 2009 10:16:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161858#M684635</guid>
      <dc:creator>Sam20</dc:creator>
      <dc:date>2009-03-10T10:16:53Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161859#M684636</link>
      <description>&amp;gt;11.11 doesn't comply with this specification. Even though size == 0, arguments are written at the end of dsb-&amp;gt;str.&lt;BR /&gt;&lt;BR /&gt;This may be fixed in a patch.  It should be fixed on 11.31.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;bzero(buf, S);&lt;BR /&gt;&lt;BR /&gt;You should be using the ANSI C function memset and the header &lt;STRING.H&gt;.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;Thank you very much Dennis.&lt;BR /&gt;&lt;BR /&gt;If you are happy with the answers, please read the following about assigning points:&lt;BR /&gt;&lt;A href="http://forums.itrc.hp.com/service/forums/helptips.do?#33" target="_blank"&gt;http://forums.itrc.hp.com/service/forums/helptips.do?#33&lt;/A&gt;&lt;/STRING.H&gt;</description>
      <pubDate>Tue, 10 Mar 2009 15:44:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161859#M684636</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2009-03-10T15:44:20Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161860#M684637</link>
      <description>&amp;gt;This may be fixed in a patch. It should be &amp;gt;fixed on 11.31.&lt;BR /&gt;&lt;BR /&gt;Good to know. Even though recent versions of vprintf man page look unchanged..&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;bzero(buf, S);&lt;BR /&gt;&amp;gt;&lt;BR /&gt;&amp;gt;You should be using the ANSI C function &amp;gt;memset and the header &lt;STRING.H&gt;.&lt;BR /&gt;&lt;BR /&gt;Yes I should :-]&lt;BR /&gt;&lt;BR /&gt;&amp;gt;If you are happy with the answers, please &amp;gt;read the following about assigning points:&lt;BR /&gt;&lt;BR /&gt;Points assigned. You definitely deserve them.&lt;BR /&gt;&lt;BR /&gt;Thanks again.&lt;BR /&gt;---------------------&lt;BR /&gt;This topic is now closed.&lt;/STRING.H&gt;</description>
      <pubDate>Tue, 10 Mar 2009 16:07:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161860#M684637</guid>
      <dc:creator>Sam20</dc:creator>
      <dc:date>2009-03-10T16:07:06Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161861#M684638</link>
      <description>Solved.</description>
      <pubDate>Tue, 10 Mar 2009 16:07:40 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161861#M684638</guid>
      <dc:creator>Sam20</dc:creator>
      <dc:date>2009-03-10T16:07:40Z</dc:date>
    </item>
    <item>
      <title>Re: Heap corruption?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161862#M684639</link>
      <description>&amp;gt;ME: It should be fixed on 11.31.&lt;BR /&gt;&lt;BR /&gt;Yes, it works fine there.  My 11.23 system still has it failing.</description>
      <pubDate>Tue, 10 Mar 2009 17:37:10 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/heap-corruption/m-p/5161862#M684639</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2009-03-10T17:37:10Z</dc:date>
    </item>
  </channel>
</rss>

