Re: double free in ExecHashJoin, 9.6.12 - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: double free in ExecHashJoin, 9.6.12
Date
Msg-id CAHyXU0x7dEUC_vi-iDkR_AjQrNyfPJKxDSq8fWqUKaOFaFZ6bQ@mail.gmail.com
Whole thread Raw
In response to Re: double free in ExecHashJoin, 9.6.12  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Wed, Jul 24, 2019 at 11:01 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Thu, Jul 25, 2019 at 2:39 AM Merlin Moncure <mmoncure@gmail.com> wrote:
> > Server is generally running pretty well, and is high volume.  This
> > query is not new and is also medium volume.  Database rebooted in
> > about 4 seconds with no damage; fast enough we didn't even trip alarms
> > (I noticed this troubleshooting another issue).  We are a couple of
> > bug fixes releases behind but I didn't see anything obvious in the
> > release notes suggesting a resolved issue. Anyone have any ideas?
> > thanks in advance.
>
> > postgres: rms ysconfig 10.33.190.21(36788) SELECT(ExecHashJoin+0x5a2)[0x5e2d32]
>
> Hi Merlin,
>
> Where's the binary from (exact package name, if installed with a
> package)?  Not sure if this is going to help, but is there any chance
> you could disassemble that function so we can try to see what it's
> doing at that offset?  For example on Debian if you have
> postgresql-9.6 and postgresql-9.6-dbg installed you could run "gdb
> /usr/lib/postgresql/9.6/bin/postgres" and then "disassemble
> ExecHashJoin".  The code at "<+1442>" (0x5a2) is presumably calling
> free or some other libc thing (though I'm surprised not to see an
> intervening palloc thing).

Thanks -- great suggestion.  I'll report back with any interesting findings.

merlin



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal: type info support functions for functions that use "any" type
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] minor bugfix for pg_basebackup (9.6 ~ )