I wrote:
> Tomas Vondra <tv@fuzzy.cz> writes:
>> BTW I also see these failures in hstore:
>> ==15168== Source and destination overlap in memcpy(0x5d0fed0, 0x5d0fed0, 40)
>> ==15168== at 0x4C2E00C: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
>> ==15168== by 0x15419A06: hstoreUniquePairs (hstore_io.c:343)
>> ==15168== by 0x15419EE4: hstore_in (hstore_io.c:416)
> Huh ...
I tried to duplicate this on my RHEL6 workstation, and failed to,
even though adding an assertion easily proves that the hstore
regression test does exercise the case. So apparently the answer
as to why skink isn't reporting this is just "not all versions of
valgrind check it".
I checked the git history and noted that we've previously fixed other
nominally-undefined usage of memcpy() on the grounds that OpenBSD's
libc will complain about it. So it seems like something that would
be good to fix, and I did so.
Meanwhile, skink has come back with a success as of 0f2458f, rendering
the other mystery even deeper --- although at least this confirms the
idea that the crashes we are seeing predate the generation.c patch.
regards, tom lane