memcpy calls causing segmentation error

[ssylee]

What kind of operations with memcpy usually result in segmentation
errors? Anything that I've missed from the following:

a) pointer manipulation of memory that is not allocated
b) improper pointer dereferencing

Thanks.

 

[guidoreina]

What kind of operations with memcpy usually result in segmentation
errors? Anything that I've missed from the following:

a) pointer manipulation of memory that is not allocated
b) improper pointer dereferencing

Thanks.

Hi,

you might have also copied beyond what you have actually allocated.

Example:
char buf[4];
memcpy(buf, "123456", 6);

Regards.

 

[Jens Thoms Toerring]

What kind of operations with memcpy usually result in segmentation
errors? Anything that I've missed from the following:

a) pointer manipulation of memory that is not allocated
b) improper pointer dereferencing

I don't know what exactly you mean with the above two points,
(and how they differ) so let me rephrase it a bit: whenever
not all of the source and destination memory area "belongs"
to your process (i.e. is either allocated memory or a vari-
able or array in scope) then you invoke undefined behaviour.
And one possible result of that can be a segmentation fault.
If you get a segmentation fault depend on the details of the
situation as well as on what kind of system you're using.
And another way of invoking undefined behaviour with memcpy()
is to use overlapping source and destination memory areas, so
also that could, theoretically, result in a segmentation fault.

Regards, Jens

 

[Guest]

What kind of operations with memcpy usually result in segmentation
errors? Anything that I've missed from the following:

a) pointer manipulation of memory that is not allocated
b) improper pointer dereferencing

Thanks.

You've got 3 parameters in memcpy. So, any kind of error on each of them
may lead to a segmentation fault.

1. First parameter:
1.1. Destination memory area not readable/writable:

char *dest = 0x0;
memcpy (dest, "lol", 3);

1.2. No check on destination memory area allocation:

char *dest = (char*) malloc(0xFFFFFFFF); // Allocation fails
memcpy (dest, "lol", 3);

2. Second parameter:
See 1.

3. Third parameter:
3.1. Size is negative. memcpy's third parameter is unsigned int.
So, a negative parameter will be considered as its positive 2's
complement.

memcpy (dest, src, -1); // -1 == 0xFFFFFFFF -> size too large

3.2. Size is bigger than what dest may contain

char dest[4];
memcpy (dest, "lolwut?", 7);

Hope I've answered your question...

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/CM/CC/E/IT/LS/M d-(--) C++++$ UBL++++$ P++++ L+++++$ E--- W+++ w--
PS+++ PE-- Y++ PGP+++ R++ tv-- b++>+++ D+ G>+++ e++>+++++ h* r++ z+++
------END GEEK CODE BLOCK------

 

[Keith Thompson]

You've got 3 parameters in memcpy. So, any kind of error on each of them
may lead to a segmentation fault.

1. First parameter:
1.1. Destination memory area not readable/writable:

char *dest = 0x0;
memcpy (dest, "lol", 3);

1.2. No check on destination memory area allocation:

char *dest = (char*) malloc(0xFFFFFFFF); // Allocation fails
memcpy (dest, "lol", 3);

That's just a special case of passing a null pointer. Passing a
non-null but invalid pointer can cause similar problems.

2. Second parameter:
See 1.

3. Third parameter:
3.1. Size is negative. memcpy's third parameter is unsigned int.
So, a negative parameter will be considered as its positive 2's
complement.

Strictly speaking, since the size is unsigned, it can't be negative.

memcpy (dest, src, -1); // -1 == 0xFFFFFFFF -> size too large

The 2's-complement of -1 would be +1, assuming a 2's-complement
representation for signed int. The actual value passed would be
SIZE_MAX, or equivalently (size_t)-1, which may or may not be
0xFFFFFFFF. And on some systems, this might even be valid.

3.2. Size is bigger than what dest may contain

char dest[4];
memcpy (dest, "lolwut?", 7);

Your 3.1 is just a special case of 3.2.

 

[Ben Bacarisse]

You've got 3 parameters in memcpy. So, any kind of error on each of them
may lead to a segmentation fault.

1. First parameter:
1.1. Destination memory area not readable/writable:

char *dest = 0x0;
memcpy (dest, "lol", 3);

A better example might be with char *dest = "a string literal"; since
that captures the words you use quite accurately. Otherwise...

1.2. No check on destination memory area allocation:

char *dest = (char*) malloc(0xFFFFFFFF); // Allocation fails
memcpy (dest, "lol", 3);

.... 1.1 and 1.2 are really the same.

The OP's request looks like homework so I was wary of answering but I
may as well now: there is another more subtle error that can occur
because the source and destination areas overlap.

 

[Pranav]

One more thing to note is that your destination is not a constant
pointer, like pointer to a string literal,

 

[Barry Schwarz]

One more thing to note is that your destination is not a constant
pointer, like pointer to a string literal,

I'll assume you meant pointer to const and not const pointer.
Unfortunately, string literals are not const in C, even though they
are immutable. So while it is, in my opinion, often advantageous to
declare such pointers as
const char* ...;
there is no requirement by the language to do so.

 

[Flash Gordon]

I'll assume you meant pointer to const and not const pointer.
Unfortunately, string literals are not const in C, even though they
are immutable. So while it is, in my opinion, often advantageous to
declare such pointers as
const char* ...;
there is no requirement by the language to do so.

Be fair, Pranav did say constant rather than const, although I agree he
should have said "pointer to constant" rather than "constant pointer".
Also they are not required to be immutable (attempting to modify them
invokes undefined behaviour so it is allowed to succeed in modifying
them and, on some implementations, *will* succeed).

Whilst string literals are not required to be immutable/constant (and
are required to NOT be const) the programmer is effectively required to
treat them as such.

 

[Pranav]

Apologies, Pointer To Constant .., Will you tell Barry why string
literals are Not needed?

 

[CBFalconer]

Apologies, Pointer To Constant .., Will you tell Barry why string
literals are Not needed?

If you want to post a followup via groups.google.com, ensure you
quote enough for the article to make sense. Google is only an
interface to Usenet; it's not Usenet itself. Don't assume your
readers can, or ever will, see any previous articles.

More details at: <http://cfaj.freeshell.org/google/>

 

[Keith Thompson]

If you want to post a followup via groups.google.com, ensure you
quote enough for the article to make sense. Google is only an
interface to Usenet; it's not Usenet itself. Don't assume your
readers can, or ever will, see any previous articles.

More details at: <http://cfaj.freeshell.org/google/>

Google Groups is no longer part of the problem, so there's not much
point in mentioning it. By default, followups in GG include proper
quotations. To post a followup without context, you have to
explicitly delete the quoted material. (At least this was true last
time I checked.)

 

[CBFalconer]

Google Groups is no longer part of the problem, so there's not much
point in mentioning it. By default, followups in GG include proper
quotations. To post a followup without context, you have to
explicitly delete the quoted material. (At least this was true last
time I checked.)

I guess I'll delete that reference. Thanks.

 

[Keith Thompson]

I guess I'll delete that reference. Thanks.

I wouldn't delete it. When Google Groups finally fixed the quoting
problem, Chris, the owner of the page, updated it to acknowledge the
fix. The page also contains some valuable links on how to post to
Usenet.