Not Getting Segmentation Fault

Question

Consider this simple code fragment :

  {  
 if(fork())
 {
printf("Parent terminated\n"); 
}
 else
 {
   char *s = "hello world";
  *s = 'H';
 printf("child terminated\n");
 }
wait(NULL);
  return 0;
}

When I compile it I dont get a segmentation fault error as we expect while assigning to *s The output is : Parent Terminated ( without printing child terminated)

Now if I remove the two lines char *s=......'H' I get the normal output .
Can someone please explain this

Seriously: meditate about the implications of **undefined** behaviour. Whoever you mean with "we" - it is not me or other C experts. "We" always expect nasal demons. — too honest for this site, Dec 11 '15 at 13:01
@Olaf the pointer is not initialised . When those two lines are compiled as an independent program we will get seg fault — Anushman, Dec 11 '15 at 13:01
One of the many possibilities of *undefined behavior* is that it might seem to work. Another is [nasal demons](http://www.catb.org/jargon/html/N/nasal-demons.html). — Some programmer dude, Dec 11 '15 at 13:02
1) There is no "Chef". 2) No, we will not necessarily get segfault! — too honest for this site, Dec 11 '15 at 13:02
#include int main() { char *s="Hello World"; *s='H'; return 0; } When i am compiling it I get a segmentation fault . — Anushman, Dec 11 '15 at 13:08
@Anushman I am still confused , how can you possibly get segmentation fault while compiling ? — ameyCU, Dec 11 '15 at 13:11
@Anushman And problem In your code is `*s='H'` . `s` is a constant you can't modify it . Instead declare and initialize your string as `char s[]="Hello World";` . — ameyCU, Dec 11 '15 at 13:13
I understand that why i get seg fault . But y DONT WE get it in above code ... where it is expected . Ichecked many cases and of seg faults and just as in this case i am not getting any error when such wrong codes are put in child process — Anushman, Dec 11 '15 at 13:14
That kind of code get no segfault at compile time, but the run time. — Michi, Dec 11 '15 at 13:42
@szczurcio no idea. If I was not already ready to downvote from the title, (it was obviously going to be UB), then I would have downvoted for the formatting. — Martin James, Dec 11 '15 at 14:34
Wellcome to SO. Please search the site for similar questions before you ask one yourself. If you then decide to do so, please take more care when writing it, in particular indent your code. — Jens Gustedt, Dec 11 '15 at 16:32
@JensGustedt That's not a very good duplicate. I think the OP knows that the code isn't supposed to work, but was wondering why there was no error message (there is one, it's just supressed) — Colonel Thirty Two, Dec 11 '15 at 17:45

score 3 · Accepted Answer · answered Dec 11 '15 at 13:17

First of all, you aren't guarenteed to get a segmentation fault, or any defined behavior, for triggering undefined behavior, such as modifying a string literal. Though on Linux, string literals are put into read-only memory, so modifying them on Linux will usually result in a segmentation fault.

So why doesn't this code trigger a segfault? It does, but you just don't see it, because you forked.

The "Segmentation Fault (core dumped)" message is printed by your shell (ex. bash), when it detects, by calling wait, when the process it spawned terminates with a SIGSEGV (segfault) signal. However, your shell will not receive any notifications about child processes exiting; your parent process will.

Your parent process calls wait to wait and get the exit code when it terminates. If you weren't ignoring the exit code by passing in NULL to wait, you'd probably see that the exit code is -11, or -SIGSEGV.

So it is segfaulting; your parent process is just ignoring the child's notification that it segfaulted.

Thanks .. and does a running child process stop if its parent is terminated — Anushman, Dec 11 '15 at 13:22
Perfect, just ready for copypasta into homework due tomorrow:( — Martin James, Dec 11 '15 at 14:36
@MartinJames Doesn't really seem like a homework problem; I can see someone getting confused as to why their code isn't displaying an error that it should be. — Colonel Thirty Two, Dec 11 '15 at 14:37

score 1 · Answer 2 · answered Dec 11 '15 at 13:17

Firstly, what others said is correct: the behavior is undefined and you cannot depend on any behavior in particular when doing this.

However, I suspect what's happening is that the child actually is having a segmentation fault. However, the familiar "Segmentation fault" message you see in your terminal is actually printed by your shell when something you run seg faults.

But, since this is a child of something you ran, your shell didn't notice. If you have configured core dumps (e.g. ulimit -c unlimited) I expect you will find a core file from the seg faulted child process.

Not Getting Segmentation Fault

2 Answers2