memcpy of overlapping buffers

Question

I ran into strange behavior when using the Aztec linear system solver library. Using valgrind, I found out that this library does a memcpy on overlapping buffers. Specification says that behavior of memcpy on overlapping buffers is not defined.

It turns out that memcpy on many machines has the same behavior as if you would do it with a for loop and therefore you can safely copy from a higher source to a lower destination:

for(int i = 0; i < len; i ++)
  dest[i] = source[i];

BUT on our large cluster, memcpy of overlapping buffers has a different behavior which leads to problems.

Now I wonder whether the overlapping memcpy in the library is normal or just caused by another bug in my code. Since the library is widely used I assume that the memcpy issue should have been discovered earlier. On the other hand, it's still possible that the vast majority of the memcpy implementations behave like the for loop and therefore nobody ever encountered this problem.

• Can anyone tell me about his experiences with overlapping memcpy on various machines?
• Which part of my computer system does actually provide memcpy?

I'd like to point out that question is about the practical experience with various implementations, not about what the specification says.

Solution 1

I've done some research on this in the past... on Linux, up until fairly recently, the implementation of memcpy() worked in a way that was similar enough to memmove() that overlapping memory wasn't an issue, and in my experience, other UNIXs were the same. This doesn't change the fact that this is undefined behavior according to the standard, and you are just lucky that on some platforms it sometimes works -- and memmove() is the standard-supported right answer.

However, in 2010, the glibc maintainers rolled out a new, optimized memcpy() that changed the behavior of memcpy() for some Intel core types where the C standard library is compiled to be faster, but no longer works like memmove() [1]. (I seem to recall also that this is new code triggered only for memory segments larger than 80 bytes). Interestingly, this caused things like the Linux version of Adobe's Flash player to break[2], as well as several other open-source packages (back in 2010 when Fedora Linux became the first to adopt the changed memcpy() in glibc).

• [1] https://sourceware.org/bugzilla/show_bug.cgi?id=12518
• [2] https://bugzilla.redhat.com/show_bug.cgi?id=638477

Solution 2

memcpy() doesn't support overlapping memory. This allows for optimizations that won't work if the buffers do overlap.

There's not much to really look into, however, because C provides an alternative that does support overlapping memory: memmove(). Its usage is identical to memcpy(). You should use it if the regions might overlap, as it accounts for that possibility.

Comments

[Michael]

The specification is clear about that. But I wonder whether the library regularly does such memcpy and nobody ever encountered this problem because the vast majority of implementations behave like the for loop OR whether I just have to assume a bug in the code driving the library.

[FatalError]

If you found the library making such a call it's either 1) A bug in the library itself, or 2) A bug in how the library was used such that memory that shouldn't have overlapped did. The fact that there are cases where it does work, doesn't make it not a bug, however.

[Michael]

That's exactly the answer I was looking for. So therefore it's perfectly possible that this behavior has been in that library for many years, never causing problems...

[JohnH]

Exactly right. I was bitten by it when moving old code to a new server with the new changes.

[jwd]

For further reading: "The memcpy vs. memmove saga". There was, and still is today, some fallout as a result of that glibc change.

[JohnH]

Thanks @jwd - Fantastic read... this one just keeps on giving. sigh