setsid() dumps core

[Manish_14]

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,

system("bash run_command.sh command_name");

where run_command.sh is a bash shell script which takes the command_name as argument and executes it.

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.

regards and thanks in advance
-Manish

[Dietmar Konermann]

The shell (in this case bash) returns 139 if its child (in this case command_name) died after receiving SIGSEGV, segmentation violation.

If your system() call returns 139, then I would think that your "big program" died... then you would need to start trouble-shooting there.

Check with "file core" what process really wrote it.

Best regards...
Dietmar.

[Manish_14]

Thanks for replying Dietmar,

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.
Is it some issue with the terminal ownership or something internal like group id making any difference??

[Dietmar Konermann]

Segmentation violations usually happen when invalid memory addresses are accessed by a process... typically due to some coding error.

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.

Best regards...
Dietmar.

[Manish_14]

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??

regards and thanks,
-Manish

[A. Clay Stephenson]

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.

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.

I'm betting it's something like a string pointer that has gone out of scope and was auto declared.

[Adam J Markiewicz]

Hi A.Clay

It would be interesting, as I'm going to argue with you a little bit. (with the most famos 'A.' in this forum, yeah!) :)

According to man setsid():
>>
If the calling process is not a process group leader, setsid() creates
a new session. The calling process becomes the session leader of this
new session, it becomes the process group leader of a new process
group, and it has no controlling terminal.
<<<

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.

However.

1. I can be wrong (and this means A.Clay wins... booooo...)
2. In either case his suggestion with core debugging is briliant. :)


Good luck
Adam

[A. Clay Stephenson]

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.