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

Поиск
Список
Период
Сортировка
Искать
От
Oleksandr Shulgin
Тема
Re: BUG #13571: sql-only extension segfaults backend during creation
Дата
Msg-id
87k2sy6mry.fsf@ashulgin01.corp.ad.zalando.net
Ответ на
Список
Дерево обсуждения
BUG #13571: sql-only extension segfaults backend during creation feikesteenbergen@gmail.com
Re: BUG #13571: sql-only extension segfaults backend during creation Oleksandr Shulgin <oleksandr.shulgin@zalando.de>
Re: BUG #13571: sql-only extension segfaults backend during creation Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #13571: sql-only extension segfaults backend during creation "Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>
Re: BUG #13571: sql-only extension segfaults backend during creation Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #13571: sql-only extension segfaults backend during creation Feike Steenbergen <feikesteenbergen@gmail.com>
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
В списке pgsql-bugs по дате отправления
От: Feike Steenbergen
Дата:
От: Tom Lane
Дата:
FAQ