<?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: Core in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982063#M122298</link>
    <description>Hi&lt;BR /&gt;&lt;BR /&gt;AFAIK there is no dedicated mechanism to block core generation.&lt;BR /&gt;&lt;BR /&gt;However check the following:&lt;BR /&gt;1. Doesn't your executable change its working directory? Corefile is always created in current directory at the moment of generation.&lt;BR /&gt;2. Does your executable have permission to create new files in its working directory?&lt;BR /&gt;3. Check value of ulimit - this is sometimes used to block core generation.&lt;BR /&gt;&lt;BR /&gt;Good luck&lt;BR /&gt;Adam&lt;BR /&gt;</description>
    <pubDate>Tue, 27 May 2003 08:45:29 GMT</pubDate>
    <dc:creator>Adam J Markiewicz</dc:creator>
    <dc:date>2003-05-27T08:45:29Z</dc:date>
    <item>
      <title>Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982062#M122297</link>
      <description>I have created an executable with gcc compiler. It is giving segmentation fault while executing, But not dumping core file. What is the option to set for dumping the core?</description>
      <pubDate>Tue, 27 May 2003 02:38:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982062#M122297</guid>
      <dc:creator>Pratheesh</dc:creator>
      <dc:date>2003-05-27T02:38:55Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982063#M122298</link>
      <description>Hi&lt;BR /&gt;&lt;BR /&gt;AFAIK there is no dedicated mechanism to block core generation.&lt;BR /&gt;&lt;BR /&gt;However check the following:&lt;BR /&gt;1. Doesn't your executable change its working directory? Corefile is always created in current directory at the moment of generation.&lt;BR /&gt;2. Does your executable have permission to create new files in its working directory?&lt;BR /&gt;3. Check value of ulimit - this is sometimes used to block core generation.&lt;BR /&gt;&lt;BR /&gt;Good luck&lt;BR /&gt;Adam&lt;BR /&gt;</description>
      <pubDate>Tue, 27 May 2003 08:45:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982063#M122298</guid>
      <dc:creator>Adam J Markiewicz</dc:creator>
      <dc:date>2003-05-27T08:45:29Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982064#M122299</link>
      <description>Hi&lt;BR /&gt;&lt;BR /&gt;TOC button on back of server/workstation ?&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Paula</description>
      <pubDate>Tue, 27 May 2003 08:52:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982064#M122299</guid>
      <dc:creator>Paula J Frazer-Campbell</dc:creator>
      <dc:date>2003-05-27T08:52:08Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982065#M122300</link>
      <description>Don't push the TOC button as suggested by Paula</description>
      <pubDate>Tue, 27 May 2003 09:16:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982065#M122300</guid>
      <dc:creator>Jdamian</dc:creator>
      <dc:date>2003-05-27T09:16:58Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982066#M122301</link>
      <description>Hi,&lt;BR /&gt;The core file is not generated because may be the size of the coredump file is fixed to zero&lt;BR /&gt; Check whether the following entry is there in the ".cshrc" file&lt;BR /&gt; "limit coredumpsize 0". &lt;BR /&gt;  If so please remove this line from the ".cshrc" file.&lt;BR /&gt;&lt;BR /&gt;Regards&lt;BR /&gt;Dipu</description>
      <pubDate>Tue, 27 May 2003 09:45:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982066#M122301</guid>
      <dc:creator>Dipu</dc:creator>
      <dc:date>2003-05-27T09:45:52Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982067#M122302</link>
      <description>check with ulimit -a for &lt;BR /&gt;coredump size.set with ulimit -c.&lt;BR /&gt;Are you using any gcc flags?Can also use&lt;BR /&gt;gdb with your build program and do tracing.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 27 May 2003 10:38:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982067#M122302</guid>
      <dc:creator>Zeev Schultz</dc:creator>
      <dc:date>2003-05-27T10:38:52Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982068#M122303</link>
      <description>The DEFAULT action for a segmentation violation is to dump core but that could have been circumvented by 1) ulimit -c 0 to limit the core file size to zero 2) having a custom SIGSEGV handler somewhere in your code (or a library) that replaces the default handler.&lt;BR /&gt;</description>
      <pubDate>Tue, 27 May 2003 13:21:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982068#M122303</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2003-05-27T13:21:38Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982069#M122304</link>
      <description>The DEFAULT action for a segmentation violation is to dump core but that could have been circumvented by 1) ulimit -c 0 to limit the core file size to zero 2) having a custom SIGSEGV handler somewhere in your code (or a library) that replaces the default handler.&lt;BR /&gt;</description>
      <pubDate>Tue, 27 May 2003 13:21:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982069#M122304</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2003-05-27T13:21:42Z</dc:date>
    </item>
    <item>
      <title>Re: Core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982070#M122305</link>
      <description>The DEFAULT action for a segmentation violation is to dump core but that could have been circumvented by 1) ulimit -c 0 to limit the core file size to zero 2) having a custom SIGSEGV handler somewhere in your code (or a library) that replaces the default handler.&lt;BR /&gt;&lt;BR /&gt;Manually inducing a program crash to cause a core dump is useless because the cause of your core dump (and thus the stack trace) would be completely unrelated to your problem.&lt;BR /&gt;&lt;BR /&gt;Do a ulimit -a and see if the core file size is not set to zero. If it is zero, you've found your answer but otherwise you must examine your code for interrupt handlers.&lt;BR /&gt;</description>
      <pubDate>Tue, 27 May 2003 13:25:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/core/m-p/2982070#M122305</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2003-05-27T13:25:03Z</dc:date>
    </item>
  </channel>
</rss>

