>>>>> "sasha" == sasha <sasha@stripped> writes:
sasha> Some strange bug in the implementation of memcpy() on Linux/Alpha (RedHat 6.1,
sasha> and possibly others) that I was not able to duplicate outside of mysqld was the
sasha> cause of the recently reported bugs on datetime, timestamp, and not sure if the
sasha> bigint bug was reported, but if you are running a recent version on MySQL (
sasha> 3.23.8 and later for sure) on Linux/Alpha Redhat 6.1, it is there. It seems
> like
sasha> everything taking 8 bytes was affected ( other than char(8) ) -- some garbage
> is
sasha> stored instead of the value. Below is a temporary patch just for Linux/Alpha,
> do
sasha> not apply it if you are on another system. We will create a more permanent fix
sasha> in the next release, that will just enable the workaround if something is
sasha> #defined by configure that has detected a broken memcpy() . In the meantime, if
sasha> you are experiencing problems, here it is :
<cut>
sasha> As you can see, I just #define memcpy to go through my hacked implementation,
sasha> that *will* memcpy, although maybe not very efficiently. I will take a look at
sasha> how memcpy() is implemented in glibc to see if I can find a clue of what is
sasha> wrong with it.
A easy fix is to just call bmove() (a version of memcpy that already
exists in our string library). I shall add a check for this to the
next MySQL version; My guess is that the bug isn't in the glibc
library but in how gcc+glibc optimizes away memcpy when the size is a
constant.
I shall add a define for this to the next MySQL version that will fix
this until we have this properly debugged.
Regards,
Monty
