Re: PL/Perl Does not Like vstrings - Mailing list pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:
> On 01/04/2012 03:56 PM, Tom Lane wrote:
>> I think what's being passed *is* an SV --- at least, the contents look
>> reasonable in gdb --- but for some reason SvPVutf8 isn't coping with
>> this particular kind of SV.  Googling suggests that SvPVutf8 used to
>> fail on READONLY SVs, of which this is one if I'm reading the flag bits
>> correctly; but that was supposedly fixed years ago.  I believe we've hit
>> some other undocumented limitation of that function, which the Perl guys
>> may or may not acknowledge as a bug once we've tracked it down better.

> Well, the crash is apparently solved by the following, which your 
> investigation suggested to me:
> -       cmsg = sv2cstr(msg);
> +       cmsg = sv2cstr(newSVsv(msg));

That's kinda grotty ... and leaky ...

I installed perl-debuginfo and soon found that SvPVutf8 leads to here:

(gdb) s
9066                    Perl_croak(aTHX_ "Can't coerce readonly %s to string in %s",
(gdb) bt
#0  Perl_sv_pvn_force_flags (my_perl=0x17f3170, sv=0x18b6c50,    lp=0x7fffb0c8e2f8, flags=<optimized out>) at
sv.c:9066
#1  0x00000038c30c7003 in Perl_sv_utf8_upgrade_flags_grow (my_perl=0x17f3170,    sv=0x18b6c50, flags=2, extra=0) at
sv.c:3228
#2  0x00000038c30c7778 in Perl_sv_2pvutf8 (my_perl=0x17f3170, sv=0x18b6c50,    lp=0x7fffb0c8e370) at sv.c:3079
#3  0x00007f4308447614 in sv2cstr (sv=0x18b6c50) at plperl_helpers.h:54
#4  0x00007f430844771f in do_util_elog (level=18, msg=0x18b6c50) at Util.xs:44
#5  0x00007f4308447bdc in XS__elog (my_perl=0x17f3170, cv=0x181e008)   at Util.xs:105
#6  0x00000038c30b548f in Perl_pp_entersub (my_perl=0x17f3170) at pp_hot.c:3046
#7  0x00000038c30ac796 in Perl_runops_standard (my_perl=0x17f3170) at run.c:41
#8  0x00000038c30480ae in Perl_call_sv (my_perl=0x17f3170, sv=0x19843e0,    flags=10) at perl.c:2647
#9  0x00007f4308440f3e in plperl_call_perl_func (desc=0x7fffb0c8e8b0,    fcinfo=0x7fffb0c8fe10) at plperl.c:2018
#10 0x00007f430843fa99 in plperl_inline_handler (fcinfo=0x7fffb0c902a0)   at plperl.c:1751

which leads to a few conclusions:

1. SvPVutf8 fails on readonly SVs, despite the fact that no such
limitation is documented and that this was supposedly fixed in 2004, cf
http://www.nntp.perl.org/group/perl.perl5.porters/2004/03/msg89505.html
We ought to hold somebody's feet to the fire about that.  I don't really
expect any response beyond documenting the limitation in perlapi, but
at least they ought to do that.

2. A slightly cleaner fix for this should be to duplicate the SV and
then release the copy around the SvPVutf8 call, only if it's readonly.
"Fixing" it in do_util_elog is entirely the wrong thing.

3. Perl_croak inside a PG_TRY block fails quite nastily.  I think we
might be well advised to move the sv2cstr(msg) call outside the PG_TRY,
but I'm wondering whether there is not a more general structural problem
in plperl concerning nesting of PG and Perl error recovery.
        regards, tom lane