<?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: setsid() dumps core in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930652#M818372</link>
    <description>Segmentation violations usually happen when invalid memory addresses are accessed by a process... typically due to some coding error.&lt;BR /&gt;&lt;BR /&gt;But if several programs have that problem, then I would especially check if enough swap space is available and if maxdsiz[-64bit] is configured large enough. Sometimes a NULL returned my malloc() is not handled gracefully... of course a programming flaw also.&lt;BR /&gt;&lt;BR /&gt;Best regards...&lt;BR /&gt; Dietmar.</description>
    <pubDate>Wed, 19 Mar 2003 12:35:36 GMT</pubDate>
    <dc:creator>Dietmar Konermann</dc:creator>
    <dc:date>2003-03-19T12:35:36Z</dc:date>
    <item>
      <title>setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930649#M818369</link>
      <description>I wrote a C program to start a big executable in a different process group. So I forked a new process and then changed its group id using setsid(). I started the big program using system(), its something like this, &lt;BR /&gt;&lt;BR /&gt;system("bash run_command.sh command_name"); &lt;BR /&gt;&lt;BR /&gt;where run_command.sh is a bash shell script which takes the command_name as argument and executes it. &lt;BR /&gt;&lt;BR /&gt;Now, whenever I execute a big program I am getting a core dump with exit code 139, I don't know what exactly the problem is. If you need I can send the source code also.&lt;BR /&gt;&lt;BR /&gt;regards and thanks in advance&lt;BR /&gt;-Manish&lt;BR /&gt;</description>
      <pubDate>Wed, 19 Mar 2003 10:05:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930649#M818369</guid>
      <dc:creator>Manish_14</dc:creator>
      <dc:date>2003-03-19T10:05:45Z</dc:date>
    </item>
    <item>
      <title>Re: setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930650#M818370</link>
      <description>The shell (in this case bash) returns 139 if its child (in this case command_name) died after receiving SIGSEGV, segmentation violation.&lt;BR /&gt;&lt;BR /&gt;If your system() call returns 139, then I would think that your  "big program" died... then you would need to start trouble-shooting there.&lt;BR /&gt;&lt;BR /&gt;Check with "file core" what process really wrote it.&lt;BR /&gt;&lt;BR /&gt;Best regards...&lt;BR /&gt; Dietmar.</description>
      <pubDate>Wed, 19 Mar 2003 11:19:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930650#M818370</guid>
      <dc:creator>Dietmar Konermann</dc:creator>
      <dc:date>2003-03-19T11:19:46Z</dc:date>
    </item>
    <item>
      <title>Re: setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930651#M818371</link>
      <description>Thanks for replying Dietmar,&lt;BR /&gt;&lt;BR /&gt;This seems to be very critical problem, the "big program" only dumping the core. The behaviour is not the same for every command which executes through this program. Some programs dump core, can not catagorize them. &lt;BR /&gt;Is it some issue with the terminal ownership or something internal like group id making any difference??</description>
      <pubDate>Wed, 19 Mar 2003 11:36:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930651#M818371</guid>
      <dc:creator>Manish_14</dc:creator>
      <dc:date>2003-03-19T11:36:07Z</dc:date>
    </item>
    <item>
      <title>Re: setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930652#M818372</link>
      <description>Segmentation violations usually happen when invalid memory addresses are accessed by a process... typically due to some coding error.&lt;BR /&gt;&lt;BR /&gt;But if several programs have that problem, then I would especially check if enough swap space is available and if maxdsiz[-64bit] is configured large enough. Sometimes a NULL returned my malloc() is not handled gracefully... of course a programming flaw also.&lt;BR /&gt;&lt;BR /&gt;Best regards...&lt;BR /&gt; Dietmar.</description>
      <pubDate>Wed, 19 Mar 2003 12:35:36 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930652#M818372</guid>
      <dc:creator>Dietmar Konermann</dc:creator>
      <dc:date>2003-03-19T12:35:36Z</dc:date>
    </item>
    <item>
      <title>Re: setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930653#M818373</link>
      <description>I think I forgot to mention one point. If I don't change the group id of the forked process (i.e. if I remove setsid() system call), everything works fine, no segmentation violation at all. So, I can put my problem in this way that, my "big program" dumps core when it is in different process group. So, something is happening behind the scene when I use setsid(), but what??&lt;BR /&gt;&lt;BR /&gt;regards and thanks,&lt;BR /&gt;-Manish</description>
      <pubDate>Wed, 19 Mar 2003 13:02:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930653#M818373</guid>
      <dc:creator>Manish_14</dc:creator>
      <dc:date>2003-03-19T13:02:38Z</dc:date>
    </item>
    <item>
      <title>Re: setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930654#M818374</link>
      <description>Even with your last bit of data (and you probably won't believe me), I would still think the chances of setsid() causing a segmentation violation are slight. Because, the hardware only detects segmentation violations that cross page boudaries, errors can go unnoticed until the code changes slightly. For example, a reference to array index out of bounds might workfine until more code were added. I've never had the smallest hiccup using setsid(). It's also not clear when you fork which is dying- the parent or the child.&lt;BR /&gt;&lt;BR /&gt;If this were me, I would turm off the optimizer, compile with -g, let it die, and examine the corefile with the debugger - do a stacktrace. That should zero in on the problem. &lt;BR /&gt;&lt;BR /&gt;I'm betting it's something like a string pointer that has gone out of scope and was auto declared.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 19 Mar 2003 14:17:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930654#M818374</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2003-03-19T14:17:22Z</dc:date>
    </item>
    <item>
      <title>Re: setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930655#M818375</link>
      <description>Hi A.Clay&lt;BR /&gt;&lt;BR /&gt;It would be interesting, as I'm going to argue with you a little bit. (with the most famos 'A.' in this forum, yeah!) :)&lt;BR /&gt;&lt;BR /&gt;According to man setsid():&lt;BR /&gt;&amp;gt;&amp;gt;&lt;BR /&gt;If the calling process is not a process group leader, setsid() creates&lt;BR /&gt;a new session.  The calling process becomes the session leader of this&lt;BR /&gt;new session, it becomes the process group leader of a new process&lt;BR /&gt;group, and it has no controlling terminal.&lt;BR /&gt;&amp;lt;&amp;lt;&amp;lt;&lt;BR /&gt;&lt;BR /&gt;Look carefully at the last part. I wouldn't be surprised if this lack of terminal couldn't be the problem here. 'big program' can assume to have its terminal and try to use it.&lt;BR /&gt;&lt;BR /&gt;However.&lt;BR /&gt;&lt;BR /&gt;1. I can be wrong (and this means A.Clay wins... booooo...)&lt;BR /&gt;2. In either case his suggestion with core debugging is briliant. :)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Good luck&lt;BR /&gt;Adam&lt;BR /&gt;</description>
      <pubDate>Wed, 19 Mar 2003 15:50:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930655#M818375</guid>
      <dc:creator>Adam J Markiewicz</dc:creator>
      <dc:date>2003-03-19T15:50:09Z</dc:date>
    </item>
    <item>
      <title>Re: setsid() dumps core</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930656#M818376</link>
      <description>The "no controlling terminal" could be part of it. In fact, you depend upon it when you "daemonize" a process - the most common use of setsid(). The stack trace is the way to fight this rather than just guessing.&lt;BR /&gt;</description>
      <pubDate>Wed, 19 Mar 2003 16:11:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/setsid-dumps-core/m-p/2930656#M818376</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2003-03-19T16:11:01Z</dc:date>
    </item>
  </channel>
</rss>

