segmentation fault in strcpy

dayalan_cse · 12-18-2006, 06:24 AM

Quote:

Originally Posted by eerok

That's not really the answer. The answer is that the assignment in question creates a string literal, which will cause a segfault when you try to overwrite it no matter how many bytes are involved. (String literals are stored in protected memory.)

I misexplained what was wrong in my remarks above, as I corrected.

Of course, you also get a segfault from 'free (dest);' after dest has been overwritten.

The result of a buffer overrun as mentioned would be "undefined behavior" ... it might work, crash, or segfault. I'm pretty sure the code didn't execute to that point, though.

When there's more than one thing wrong, it's sometimes hard to nail the pertinent one.

hai eerok,

your correct. thank you.

" (String literals are stored in protected memory.) " --> this i am able to understand ( your correct )
and is there any way to see this string in protected memory ? in elf. is there any tool for that.

but the core dump results shows strcpy raises segmentation fault. i am sure it is happening in this point. but my question is if you take the same concept program with array then you will not get segmentation problem then why it is for pointer? if your answer is "protected" means how can i make sure myself is there any way to make it conform using the linux tools? can you please help me to understand the problem.

Thanks & Regards
dayalan

eerok · 12-18-2006, 09:52 AM

Quote:

Originally Posted by dayalan_cse

is there any way to see this string in protected memory ? in elf. is there any tool for that.

but the core dump results shows strcpy raises segmentation fault. i am sure it is happening in this point. but my question is if you take the same concept program with array then you will not get segmentation problem then why it is for pointer? if your answer is "protected" means how can i make sure myself is there any way to make it conform using the linux tools? can you please help me to understand the problem.

Have you been using gdb to investigate this? I'm not an expert with this kind of thing, though I've used gdb occasionally. It's probably easier to research this less directly.

It's true that an array doesn't create the problem of the string literal; a string literal is defined in the standard as a preprocessing token, so it's processed before user data areas are initialized. The standard says string literals are used to "initialize an array of static storage duration and length just sufficient to contain the sequence." (n1124.pdf "6.4.5 String literals")

Perhaps it's faster to use string literals in the case where the contents don't need to be modified, or perhaps it's sometimes desirable to protect these strings for other reasons, but I admit that the larger questions here are beyond my technical competence

dayalan_cse · 12-19-2006, 01:52 AM

Quote:

Originally Posted by matthewg42

When you do something like this:

Code:

char* c = "hello world";

...the compiler makes a static string "hello world" in the object file. This is in a read-only data segment (called .data). The variable named c, of type pointer to a char, is set to be the address of the first character of the string in the .data segment.

If you try to modify the address of the static string in the data segment, you get a segfault because that page of memory is marked as read-only.

So, in answer to the question "why does this make a segfault?", see comments here:

Code:

    dest=(char*) malloc(20);     /* After this, dest points to newly allocated
                                    memory from the heap (or NULL on failure) */
 
    dest="data1";                /* oops, you've discarded the address of your
                                    malloc'd memory, and instead set dest to 
                                    point at the static string "data1" in the 
                                    .data segment (readonly)! */

    strcpy(dest,in);             /* strcpy tries to write to the address of 
                                    "data1".  Segfault! */
    ...

hai matthew,

thanks for your good explanation. i understand the concept thank you once again.
but can you tell me is there any tools in linux to trace these kind of problems other than gdb?

thank you.
Thanks & Regards
dayalan

matthewg42 · 12-19-2006, 02:15 AM

gdb is an excellent tool for this sort of work. If you don't like the text-mode interface, there are several GUI front-ends to gdb which might be more appealing, e.g. kdbg, insight and DDD (which is a really amazing tool for debugging and learning about data structures).