Re: double free in ExecHashJoin, 9.6.12

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: double free in ExecHashJoin, 9.6.12
Date: 2019-07-25 04:00:28
Message-ID: CA+hUKGKn_e5p2c_S9ZxN9PodBz5DKRC4xi0CBAH=Phppr=Z3Bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 25, 2019 at 2:39 AM Merlin Moncure <mmoncure(at)gmail(dot)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).

--
Thomas Munro
https://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2019-07-25 04:00:50 Re: POC: Cleaning up orphaned files using undo logs
Previous Message Peter Geoghegan 2019-07-25 03:48:59 Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.