From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tv@fuzzy.cz>
cc: Andres Freund <andres@anarazel.de>, Simon Riggs <simon@2ndquadrant.com>,
        pgsql-committers <pgsql-committers@postgresql.org>
Subject: Re: pgsql: Generational memory allocator
In-reply-to: <bf84d940-90d4-de91-19dd-612e011007f4@fuzzy.cz>
References: <E1eHa4J-0006hI-Q8@gemulon.postgresql.org>
 <20171123001649.y2nf7422iay6cw3v@alap3.anarazel.de>
 <CANP8+jKoT=Pg5W_3FcKiDf+FMrJhFYacxt_g5E0=tkmb5s8M6g@mail.gmail.com>
 <c903f275-2150-fa52-64bf-dca7b53ebf8d@fuzzy.cz>
 <16449.1511548313@sss.pgh.pa.us> <4618.1511573138@sss.pgh.pa.us>
 <bf84d940-90d4-de91-19dd-612e011007f4@fuzzy.cz>
Comments: In-reply-to Tomas Vondra <tv@fuzzy.cz>
	message dated "Sat, 25 Nov 2017 05:54:18 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6188.1511587105.1@sss.pgh.pa.us>
Date: Sat, 25 Nov 2017 00:18:25 -0500
Message-ID: <6189.1511587105@sss.pgh.pa.us>
Precedence: bulk

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 ...

> Seems hstoreUniquePairs may call memcpy with the same pointers in some 
> cases (which looks a bit dubious). But the code is ancient, so it's 
> strange it didn't fail before.

Quite.  It's easy to see how to avoid the nominally-undefined behavior:

-			memcpy(res, ptr, sizeof(Pairs));
+			if (res != ptr)
+				memcpy(res, ptr, sizeof(Pairs));

but this should surely have been noticed by valgrind tests before.
The case doesn't necessarily occur --- if the first two items in
sorted order are dups, it won't --- but if you're seeing it occur
in regression testing then skink should have seen it as well.

			regards, tom lane