Re: Residual cleanups for tied objects in PL/Perl

From: Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, andrew(at)dunslane(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Residual cleanups for tied objects in PL/Perl
Date: 2026-09-30 18:35:10
Message-ID: CAB8bMisFu7xfZ_4Rh8Yvq6JHhhKuTPLT99AzDfoyTQ8j4KRauw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ср, 30 сент. 2026 г. в 21:18, Kirill Reshke <reshkekirill(at)gmail(dot)com>:

> On Wed, 19 Aug 2026 at 23:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > I wrote:
> > > I plan to study your patch more closely tomorrow.
> >
> > Pushed after some mostly-cosmetic fiddling, and I incorporated
> > your test cases from upthread. Thanks for working on this!
> >
> > regards, tom lane
> >
>
>
> HI!
> I was running some random fuzzing recently, and I bumped into another
> related issue. Not sure if this is worth fixing, but maybe it is worth
> reporting. No modules required. A trusted plperl function that returns
> a SETOF result as a tied array whose class does not implement
> FETCHSIZE exits. Fails on current master 1f7013fe089 and 19beta4
> b73d13c32c8.
>
>
> CREATE EXTENSION plperl;
>
> CREATE OR REPLACE FUNCTION pl_mf_tr() RETURNS SETOF int LANGUAGE plperl AS
> $$
> package MF;
> sub TIEARRAY { my $c = shift; bless { }, $c }
> sub FETCH { 42 }
> my @a; tie @a, 'MF';
> return \(at)a;
> $$;
>
> SELECT count(*) FROM pl_mf_tr();
>
>
> Breakpoint 1, __GI_exit (status=255) at ./stdlib/exit.c:137
> warning: 137 ./stdlib/exit.c: No such file or directory
> (gdb) bt
> #0 __GI_exit (status=255) at ./stdlib/exit.c:137
> #1 0x0000713157470bef in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #2 0x0000713157470cc6 in Perl_my_failure_exit () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #3 0x000071315756cef3 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #4 0x00007131574fd71b in Perl_croak_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #5 0x00007131574fd72d in Perl_die_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #6 0x000071315757b0b0 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #7 0x000071315751ec7e in Perl_runops_standard () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #8 0x00007131574691af in Perl_call_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #9 0x00007131574fa38a in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #10 0x00007131574fd763 in Perl_vcroak () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #11 0x00007131574fe2ea in Perl_croak () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #12 0x0000713157478eff in Perl_gv_fetchmethod_pvn_flags () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #13 0x00007131574790fc in Perl_gv_fetchmethod_sv_flags () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #14 0x000071315752f7a7 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #15 0x000071315751ec7e in Perl_runops_standard () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #16 0x00007131574691af in Perl_call_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #17 0x0000713157504368 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #18 0x0000713157504733 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #19 0x00007131575019f8 in Perl_mg_size () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #20 0x00007131643797ce in Perl_av_count (av=0x5d7778b83290,
> my_perl=0x5d7778b49cf0) at
> /usr/lib/x86_64-linux-gnu/perl/5.38/CORE/inline.h:61
> #21 Perl_av_count (av=0x5d7778b83290, my_perl=0x5d7778b49cf0) at
> /usr/lib/x86_64-linux-gnu/perl/5.38/CORE/inline.h:56
> #22 plperl_func_handler (fcinfo=<optimized out>) at plperl.c:2461
> #23 plperl_call_handler (fcinfo=0x5d7778c26630) at plperl.c:1864
>
>
>
> --
> Best regards,
> Kirill Reshke
>

Hi, Kirill!

I, Tom, and the security team are aware of it. I found this a while ago. I
proposed a patch on how to close this issue (the sec team may have their
own solution). I think the issue will be resolved in the near future.

--
Regards,
Rachitskiy Andrey

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Matheus Alcantara 2026-09-30 18:27:10 Re: postgres_fdw: transaction mode inheritance corner cases