By Vikram


2012-02-27 17:58:12 8 Comments

#include<stdio.h>

int main()
{
    char *name = "Vikram";
    printf("%s",name);
    name[1]='s';
    printf("%s",name);
    return 0;
}

There is no output printed on terminal and just get segmentation fault. But when I run it in GDB, I get following -

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400525 in main () at seg2.c:7
7       name[1]='s';
(gdb) 

This means program receive SEG fault on 7th line (obviously I can't write on constant char array) . Then why printf() of line number 6 is not executed ?

4 comments

@ouah 2012-02-27 18:45:05

By default when stdout is connected to a terminal, the stream is line-buffered. In practice, in your example the absence of '\n' (or of an explicit stream flush) is why you don't get the characters printed.

But in theory undefined behavior is not bounded (from the Standard "behavior [...] for which this International Standard imposes no requirements") and the segfault can happen even before the undefined behavior occurs, for example before the first printf call!

@John Lawrence Aspden 2017-03-29 19:17:10

So... you are saying that the behaviour is so undefined that it can act backwards in time?

@Zan Lynx 2018-09-19 23:31:47

@JohnLawrenceAspden Probably not in this case but in other programs the compiler might move an assignment to the top of the function or even execute code in parallel. Itanium machine code could do six things in one instruction bundle. Figuring out which one caused a processor trap was interesting.

@paul 2012-02-27 18:30:03

First you should end your printfs with "\n" (or at least the last one). But that is not related to the segfault.

When the compiler compiles your code, it splits the binary into several section. Some are read only, while other are writeable. Writing to an read only section may cause a segfault. String literals are usually placed in a read only section (gcc should put it in ".rodata"). The pointer name points to that ro section. Therefore you must use

const char *name = "Vikram";

In my response I've used a few "may" "should". The behaviour depends on your OS, compiler and compilation settings (The linker script defines the sections).

Adding

-Wa,-ahlms=myfile.lst

to gcc's command line produces a file called myfile.lst with the generated assembler code. At the top you can see

    .section .rodata
.LC0:
    .string "Vikram"

Which shows that the string is in Vikram.

The same code using (Must be in global scope, else gcc may store it on the stack, notice it is an array and not a pointer)

char name[] = "Vikram";

produces

    .data
    .type name, @object
    .size name, 7
name:
    .string "Vikram"

The syntax is a bit different but see how it is in .data section now, which is read-write. By the way this example works.

@Richard J. Ross III 2012-02-27 18:39:40

If you notice, the OP is not asking why the segfault occurs, but why the string wasn't printed out in the first place.

@vts 2014-05-08 16:16:19

although this may not be exactly answer to the question, the tip and explain on .rodata and .data is helpful.

@Perry 2012-02-27 18:03:23

The reason you are getting a segmentation fault is that C string literals are read only according to the C standard, and you are attempting to write 's' over the second element of the literal array "Vikram".

The reason you are getting no output is because your program is buffering its output and crashes before it has a chance to flush its buffer. The purpose of the stdio library, in addition to providing friendly formatting functions like printf(3), is to reduce the overhead of i/o operations by buffering data in in-memory buffers and only flushing output when necessary, and only performing input occasionally instead of constantly. Actual input and output will not, in the general case, occur at the moment when you call the stdio function, but only when the output buffer is full (or the input buffer is empty).

Things are slightly different if a FILE object has been set so it flushes constantly (like stderr), but in general, that's the gist.

If you're debugging, it is best to fprintf to stderr to assure that your debug printouts will get flushed before a crash.

@Mysticial 2012-02-27 18:00:38

This is due to stream buffering of stdout. Unless you do fflush(stdout) or you print a newline "\n" the output is may be buffered.

In this case, it's segfaulting before the buffer is flushed and printed.

You can try this instead:

printf("%s",name);
fflush(stdout);        //  Flush the stream.
name[1]='s';           //  Segfault here (undefined behavior)

or:

printf("%s\n",name);   //  Flush the stream with '\n'
name[1]='s';           //  Segfault here (undefined behavior)

@Aaron Dufour 2012-02-27 18:30:51

Note that fflush is really the right way to do it - a newline is not guaranteed to trigger a flush (and I've been bitten by that behavior before).

Related Questions

Sponsored Content

46 Answered Questions

[SOLVED] JavaScript equivalent to printf/String.Format

14 Answered Questions

[SOLVED] What is a segmentation fault?

8 Answered Questions

[SOLVED] segmentation fault when calling a function

2 Answered Questions

[SOLVED] SIGSEGV, Segmentation fault. while printf() value of index of an array

1 Answered Questions

[SOLVED] Can't find and fix my seg fault error

  • 2018-05-09 01:40:55
  • Michael Innamorato
  • 41 View
  • 0 Score
  • 1 Answer
  • Tags:   c segmentation-fault

3 Answered Questions

[SOLVED] Segmentation Fault on fopen

  • 2013-04-08 13:01:00
  • SwiftCore
  • 2966 View
  • 0 Score
  • 3 Answer
  • Tags:   c

2 Answered Questions

1 Answered Questions

[SOLVED] Segmentation fault inside printf statement

Sponsored Content