From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Consolidate 'unique array values' logic into a reusable function? |
Date: | 2020-01-12 20:59:59 |
Message-ID: | 20200112205959.GA2629881@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 08, 2020 at 02:49:48PM +1300, Thomas Munro wrote:
> On Sun, Dec 29, 2019 at 8:02 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > ==00:00:00:28.322 1527557== Source and destination overlap in memcpy(0x1000104, 0x1000104, 4)
> > ==00:00:00:28.322 1527557== at 0x4C2E74D: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1035)
> > ==00:00:00:28.322 1527557== by 0xA9A57B: qunique (qunique.h:34)
> > ==00:00:00:28.322 1527557== by 0xA9A843: InitCatalogCache (syscache.c:1056)
> > ==00:00:00:28.322 1527557== by 0xAB6B18: InitPostgres (postinit.c:682)
> > ==00:00:00:28.322 1527557== by 0x91F98E: PostgresMain (postgres.c:3909)
> > ==00:00:00:28.322 1527557== by 0x872DE9: BackendRun (postmaster.c:4498)
> > ==00:00:00:28.322 1527557== by 0x8725B3: BackendStartup (postmaster.c:4189)
> > ==00:00:00:28.322 1527557== by 0x86E7F4: ServerLoop (postmaster.c:1727)
> > ==00:00:00:28.322 1527557== by 0x86E0AA: PostmasterMain (postmaster.c:1400)
> > ==00:00:00:28.322 1527557== by 0x77CB56: main (main.c:210)
> > ==00:00:00:28.322 1527557==
> > {
> > <insert_a_suppression_name_here>
> > Memcheck:Overlap
> > fun:memcpy@@GLIBC_2.14
> > fun:qunique
> > fun:InitCatalogCache
> > fun:InitPostgres
> > fun:PostgresMain
> > fun:BackendRun
> > fun:BackendStartup
> > fun:ServerLoop
> > fun:PostmasterMain
> > fun:main
> > }
> >
> > This is like the problem fixed in 9a9473f; the precedent from there would be
> > to test src!=dst before calling mempcy(), e.g. as attached. I suppose the
> > alternative would be to add a suppression like the one 9a9473f removed.
>
> Thanks for fixing that.
Glad to help.
> > I do wonder why the Valgrind buildfarm animals haven't noticed.
>
> Optimisation levels? For example, I see that skink is using -Og, at
> which level my local GCC inlines qunique() and memcpy() so that in the
> case you quoted there's a MOV instruction and valgrind has nothing to
> complain about.
That explains it. I would have been using -O0. (It would be a nice bonus to
have both an -O0 Valgrind buildfarm animal and an optimized Valgrind animal,
since neither catches everything.)
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Nelson | 2020-01-12 21:43:38 | Re: refactoring - standardize integer parsing in front-end utilities |
Previous Message | Tom Lane | 2020-01-12 19:46:25 | Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?) |