Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIgTU-0007e8-Lx for pgsql-committers@arkaria.postgresql.org; Sat, 25 Nov 2017 19:50:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIgTU-0000dD-1t for pgsql-committers@arkaria.postgresql.org; Sat, 25 Nov 2017 19:50:52 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eIgTT-0000d3-QC for pgsql-committers@lists.postgresql.org; Sat, 25 Nov 2017 19:50:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eIgTQ-0004np-6E for pgsql-committers@postgresql.org; Sat, 25 Nov 2017 19:50:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vAPJofVx008992; Sat, 25 Nov 2017 14:50:41 -0500 From: Tom Lane To: Tomas Vondra cc: Andres Freund , Simon Riggs , pgsql-committers Subject: Re: pgsql: Generational memory allocator In-reply-to: <6189.1511587105@sss.pgh.pa.us> References: <20171123001649.y2nf7422iay6cw3v@alap3.anarazel.de> <16449.1511548313@sss.pgh.pa.us> <4618.1511573138@sss.pgh.pa.us> <6189.1511587105@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 25 Nov 2017 00:18:25 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8990.1511639441.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Nov 2017 14:50:41 -0500 Message-ID: <8991.1511639441@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Tomas Vondra writes: >> BTW I also see these failures in hstore: >> =3D=3D15168=3D=3D Source and destination overlap in memcpy(0x5d0fed0, 0= x5d0fed0, 40) >> =3D=3D15168=3D=3D at 0x4C2E00C: memcpy@@GLIBC_2.14 (vg_replace_strme= m.c:1018) >> =3D=3D15168=3D=3D by 0x15419A06: hstoreUniquePairs (hstore_io.c:343) >> =3D=3D15168=3D=3D 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