BUG #13571: sql-only extension segfaults backend during creation

I forgot to mention: The behaviour is intermittent, a succesfull
execution may occur.
One sure way to trigger it seems to be:

CREATE EXTENSION castbug;
DROP EXTENSION castbug;
CREATE EXTENSION castbug;

This problem does not occur on 9.4.4

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

feikesteenbergen@gmail.com writes:

The following bug has been logged on the website:

Bug reference: 13571
Logged by: Feike Steenbergen
Email address: feikesteenbergen@gmail.com
PostgreSQL version: 9.5alpha2
Operating system: Debian jessie x86_64
Description:

When installing a sql-only extension, my backend crashes taking the cluster
with it.

After some debugging we have created a reproducable testcase.

postgres@postgres=# create extension castbug;
server closed the connection unexpectedly

castbug.control:

relocatable = false
superuser = true
comment = 'This triggers a segfault on 9.5alpha2'
default_version = unstable

castbug--unstable.sql:

DO
$$
DECLARE
roles text[] := '{"job_scheduler","job_monitor"}';
BEGIN
END;
$$;

SELECT count(*)
FROM pg_class
CROSS JOIN generate_series(1,100);

DO
$$
DECLARE
something text[] := '{"jb_scheduler","job_monitr"}';
BEGIN
END;
$$;

I did a quick debugging session on this and I believe that the cast_hash
logic in pl_exec.c is to blame.

The first time get_cast_hashentry() tries to find a cast, it creates the
global hash table and inserts an entry for the cast in it, using the
current memory context, which is of the first DO block. When the first
DO block ends, the memory context is freed, but the cast_hash with all
its content stays. So the next time we're trying to find an appropriate
cast function in the second DO block, we are getting the old one, but it
is now pointing to the deallocated memory.

I'm not sure what would be the proper fix for this.

--
Alex

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Oleksandr Shulgin <oleksandr.shulgin@zalando.de> writes:

I did a quick debugging session on this and I believe that the cast_hash
logic in pl_exec.c is to blame.

Hmm ... thought I'd fixed that in 0fc94a5ba, but apparently there's still
a missed case. Will look, thanks for the report!

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Oleksandr Shulgin <oleksandr.shulgin@zalando.de> writes:

feikesteenbergen@gmail.com writes:

When installing a sql-only extension, my backend crashes taking the cluster
with it.

I did a quick debugging session on this and I believe that the cast_hash
logic in pl_exec.c is to blame.

I've pushed a fix for that. Thanks for the report!

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Sat, Aug 15, 2015 at 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Oleksandr Shulgin <oleksandr.shulgin@zalando.de> writes:

feikesteenbergen@gmail.com writes:

When installing a sql-only extension, my backend crashes taking the

cluster

with it.

I did a quick debugging session on this and I believe that the cast_hash
logic in pl_exec.c is to blame.

I've pushed a fix for that. Thanks for the report!

Thanks, I can confirm the latest master fixes it for me.

Is it going to be back-patched, at least to 9.5?

--
Alex