Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/04/2012 08:32 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: Tom said: 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. How do we tell if it's readonly? SvREADONLY(sv) macro. OK, so this seems to fix The issue David found: diff --git a/src/pl/plperl/plperl_helpers.h b/src/pl/plperl/plperl_helpers.h index ac0a97d..f0e1afa 100644 --- a/src/pl/plperl/plperl_helpers.h +++ b/src/pl/plperl/plperl_helpers.h @@ -51,7 +51,10 @@ sv2cstr(SV *sv) /* * get a utf8 encoded char * out of perl. *note* it may not be valid utf8! */ - val = SvPVutf8(sv, len); + if (SvREADONLY(sv)) + val = SvPVutf8(sv_mortalcopy(sv), len); + else + val = SvPVutf8(sv, len); /* * we use perls length in the event we had an embedded null byte to ensure but it doesn't fix the one I found which passes a typeglob to elog(): do '$foo=1; elog(NOTICE,*foo);' language plperl; That still crashes, but doesn't if we use sv_mortalcopy unconditionally. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
Andrew Dunstan and...@dunslane.net writes: On 01/04/2012 08:32 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: How do we tell if it's readonly? SvREADONLY(sv) macro. but it doesn't fix the one I found which passes a typeglob to elog(): do '$foo=1; elog(NOTICE,*foo);' language plperl; Mmm, I was wondering about that one. That still crashes, but doesn't if we use sv_mortalcopy unconditionally. Unconditional sv_mortalcopy sounds like the thing to do then, but a comment would help. And if this isn't a Perl bug, I would like to know what is. BTW, shouldn't we be making some attempt to drop the result of the sv_mortalcopy? Or is it just assumed that it will be garbage-collected before the memory leak gets too bad? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/05/2012 10:34 AM, Tom Lane wrote: Unconditional sv_mortalcopy sounds like the thing to do then, but a comment would help. And if this isn't a Perl bug, I would like to know what is. Indeed. David, can you file a bug on this? BTW, shouldn't we be making some attempt to drop the result of the sv_mortalcopy? Or is it just assumed that it will be garbage-collected before the memory leak gets too bad? Yes, it will be garbage collected before long. See discussion in perldoc perlguts. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 5, 2012, at 9:08 AM, Andrew Dunstan wrote: Unconditional sv_mortalcopy sounds like the thing to do then, but a comment would help. And if this isn't a Perl bug, I would like to know what is. Indeed. David, can you file a bug on this? I could, but don’t know what to say, and wouldn’t be able to answer any questions intelligently. I suggest you or Tom file one. Just run `perlbug` and follow the prompts. I’m sure p5p would appreciate a good bug report that I would not be able to send. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
That still crashes, but doesn't if we use sv_mortalcopy unconditionally.
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Question: Is this an issue anywhere else in PL/Perl, or just elog()? What about
SPI parameters or return values?
david=# DO LANGUAGE PLPERL $$
david$# my $plan = spi_prepare('SELECT $1', 'TEXT');
david$# spi_query_prepared($plan, $^V);
david$# spi_freeplan($plan);
david$# return;
david$# $$;
ERROR: cannot convert Perl hash to non-composite type text at line 3.
CONTEXT: PL/Perl anonymous code block
No segfault, at least, though that’s a rather bizarre error message. AFAIK, $^V
isn’t a hash. This works, though:
DO LANGUAGE PLPERL $$
my $plan = spi_prepare('SELECT $1', 'TEXT');
spi_query_prepared($plan, v1);
spi_freeplan($plan);
return;
$$;
DO
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
David E. Wheeler da...@justatheory.com writes: On Jan 5, 2012, at 7:34 AM, Tom Lane wrote: Unconditional sv_mortalcopy sounds like the thing to do then, but a comment would help. And if this isn't a Perl bug, I would like to know what is. Question: Is this an issue anywhere else in PL/Perl, or just elog()? I would imagine you could reproduce it by returning the same kinds of objects as function results, since the actual problem is in utf8 to database-encoding conversion. No segfault, at least, though thats a rather bizarre error message. AFAIK, $^V isnt a hash. This works, though: spi_query_prepared($plan, v1); Is that actually a vstring? I confess I'd never heard of the things before this thread, but I remember reading somewhere that you need multiple dots in a string before it's considered a vstring and not something else. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/05/2012 12:28 PM, David E. Wheeler wrote:
On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
That still crashes, but doesn't if we use sv_mortalcopy unconditionally.
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Question: Is this an issue anywhere else in PL/Perl, or just elog()? What about
SPI parameters or return values?
The fix that has been applied, as Tom suggested, is at the point where
we call SvPVutf8(), so that's not just for elog().
david=# DO LANGUAGE PLPERL $$
david$# my $plan = spi_prepare('SELECT $1', 'TEXT');
david$# spi_query_prepared($plan, $^V);
david$# spi_freeplan($plan);
david$# return;
david$# $$;
ERROR: cannot convert Perl hash to non-composite type text at line 3.
CONTEXT: PL/Perl anonymous code block
No segfault, at least, though that’s a rather bizarre error message. AFAIK, $^V
isn’t a hash. This works, though:
As documented, it's not a scalar, and you need to stop treating it as
one. If you want it as a scalar, which is what you'd need here, enclose
it in quotes, or use the stuff shown in perldoc perlvar.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 5, 2012, at 9:41 AM, Tom Lane wrote: I would imagine you could reproduce it by returning the same kinds of objects as function results, since the actual problem is in utf8 to database-encoding conversion. No segfault, at least, though that‚s a rather bizarre error message. AFAIK, $^V isn‚t a hash. This works, though: spi_query_prepared($plan, v1); Is that actually a vstring? I confess I'd never heard of the things before this thread, but I remember reading somewhere that you need multiple dots in a string before it's considered a vstring and not something else. Yes, it is. You can declare v-strings either by prepending a v to one or more dot-separated integers, or just 3 or more dotted integers. http://austin.pm.org/presentations/march2000/raty/vstrings.html I believe the latter syntax is deprecated, though; it turned out to be confusing and pretty roundly hated. It's preferred to use the v syntax. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 5, 2012, at 9:50 AM, Andrew Dunstan wrote: The fix that has been applied, as Tom suggested, is at the point where we call SvPVutf8(), so that's not just for elog(). Great, thanks. As documented, it's not a scalar, and you need to stop treating it as one. If you want it as a scalar, which is what you'd need here, enclose it in quotes, or use the stuff shown in perldoc perlvar. Oh, right $^V is a version object. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/05/2012 12:41 PM, Tom Lane wrote: Is that actually a vstring? I confess I'd never heard of the things before this thread, but I remember reading somewhere that you need multiple dots in a string before it's considered a vstring and not something else. perldoc perlvar says: The revision, version, and subversion of the Perl interpreter, represented as a version object. This variable first appeared in perl 5.6.0; earlier versions of perl will see an undefined value. Before perl 5.10.0 $^V was represented as a v-string. I'm quite sure David isn't running on something older than 5.10.0. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/05/2012 12:17 PM, David E. Wheeler wrote: On Jan 5, 2012, at 9:08 AM, Andrew Dunstan wrote: Unconditional sv_mortalcopy sounds like the thing to do then, but a comment would help. And if this isn't a Perl bug, I would like to know what is. Indeed. David, can you file a bug on this? I could, but don’t know what to say, and wouldn’t be able to answer any questions intelligently. I suggest you or Tom file one. Just run `perlbug` and follow the prompts. I’m sure p5p would appreciate a good bug report that I would not be able to send. OK, done. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
Andrew Dunstan and...@dunslane.net writes: The fix that has been applied, as Tom suggested, is at the point where we call SvPVutf8(), so that's not just for elog(). That patch looks good, but do we want to look into the other point about error recovery? The real bottom line here is that when SvPVutf8 threw a croak(), we didn't recover sanely at all --- in fact, it was almost impossible to tell what had happened even in gdb, until I installed perl debugging symbols and single-stepped through things. I would have hoped that we'd at least see the croak message. This seems a bit nervous-making, as plperl sure calls a lot of stuff that in principle could croak. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/05/2012 01:09 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: The fix that has been applied, as Tom suggested, is at the point where we call SvPVutf8(), so that's not just for elog(). That patch looks good, but do we want to look into the other point about error recovery? The real bottom line here is that when SvPVutf8 threw a croak(), we didn't recover sanely at all --- in fact, it was almost impossible to tell what had happened even in gdb, until I installed perl debugging symbols and single-stepped through things. I would have hoped that we'd at least see the croak message. This seems a bit nervous-making, as plperl sure calls a lot of stuff that in principle could croak. Yes, I think so. That seemed like a separate issue, though, which is why I just applied the workaround to the reported problem. I had similar issues with gdb - it wasn't a pleasant experience. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 5, 2012, at 9:55 AM, Andrew Dunstan wrote: perldoc perlvar says: The revision, version, and subversion of the Perl interpreter, represented as a version object. This variable first appeared in perl 5.6.0; earlier versions of perl will see an undefined value. Before perl 5.10.0 $^V was represented as a v-string. I'm quite sure David isn't running on something older than 5.10.0. Perl 5.14.2: perl -E 'say ref $^V' version Perl 5.12.4: perl -E 'say ref $^V' version Perl 5.10.1: perl -E 'say ref $^V' version Perl 5.8.9: perl -le 'print ref $^V' Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/04/2012 12:47 AM, David E. Wheeler wrote: Is this perhaps by design? Oy, this doesn’t look good: $ do LANGUAGE plperl $$ elog(NOTICE, $^V) $$; ERROR: server conn crashed? ERROR: server conn crashed? The connection to the server was lost. Attempting reset: Succeeded. (pgxn@localhost:5900) 06:44:42 [pgxn] $ Try elog(NOTICE, $^V) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
Andrew Dunstan and...@dunslane.net writes: On 01/04/2012 12:47 AM, David E. Wheeler wrote: Oy, this doesnt look good: $ do LANGUAGE plperl $$ elog(NOTICE, $^V) $$; The connection to the server was lost. Attempting reset: Succeeded. Try elog(NOTICE, $^V) Isn't this a Perl bug? It seems to be crashing in SvPVutf8, which means that either Perl passed something that's not an SV to a function declared to accept SVs, or that SvPVutf8 fails on some SVs. Either way, Perl is failing to satisfy the POLA if you ask me. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 4, 2012, at 12:44 AM, Andrew Dunstan wrote: Try elog(NOTICE, $^V) Yeah, I used elog(NOTICE, version-new($^V)) Which was fine. But still, it should’t segfault. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 4, 2012, at 8:15 AM, Tom Lane wrote: Isn't this a Perl bug? It seems to be crashing in SvPVutf8, which means that either Perl passed something that's not an SV to a function declared to accept SVs, or that SvPVutf8 fails on some SVs. Either way, Perl is failing to satisfy the POLA if you ask me. Possibly, though I know nothing of Perl’s internals. Someone able to come up with a simple test case? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/04/2012 11:15 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 01/04/2012 12:47 AM, David E. Wheeler wrote: Oy, this doesn’t look good: $ do LANGUAGE plperl $$ elog(NOTICE, $^V) $$; The connection to the server was lost. Attempting reset: Succeeded. Try elog(NOTICE, $^V) Isn't this a Perl bug? It seems to be crashing in SvPVutf8, which means that either Perl passed something that's not an SV to a function declared to accept SVs, or that SvPVutf8 fails on some SVs. Either way, Perl is failing to satisfy the POLA if you ask me. U, not sure. The docs (perldoc perlvar) seem to suggest $^V isn't an SV (i.e. a scalar) but some other sort of animal: $^V The revision, version, and subversion of the Perl interpreter, represented as a version object. This variable first appeared in perl 5.6.0; earlier versions of perl will see an undefined value. Before perl 5.10.0 $^V was represented as a v-string. $^V can be used to determine whether the Perl interpreter executing a script is in the right range of versions. For example: warn Hashes not randomized!\n if !$^V or $^V lt v5.8.1 To convert $^V into its string representation use sprintf()'s %vd conversion: printf version is v%vd\n, $^V; # Perl's version But Util.xs::util_elog() expects an SV and doesn't check whether or not it actually has one. I've found a few other ways of crashing this call (e.g. by passing a typeglob), so maybe we need to test that we actually have an SV. I think SvOK() is what we'd use for that - perl gurus please confirm. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
Andrew Dunstan and...@dunslane.net writes: The docs (perldoc perlvar) seem to suggest $^V isn't an SV (i.e. a scalar) but some other sort of animal: Yeah, it's a version object, but I'd have thought that SvPV and friends would automatically stringify such an object. Otherwise, practically any kind of perl extension could be crashed by passing it one, no? But Util.xs::util_elog() expects an SV and doesn't check whether or not it actually has one. I've found a few other ways of crashing this call (e.g. by passing a typeglob), so maybe we need to test that we actually have an SV. I think SvOK() is what we'd use for that - perl gurus please confirm. I looked at that last night but it appeared that SvOK would be perfectly happy. (Didn't actually try it, though, I was just eyeballing the flags in gdb.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/04/2012 12:56 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: The docs (perldoc perlvar) seem to suggest $^V isn't an SV (i.e. a scalar) but some other sort of animal: Yeah, it's a version object, but I'd have thought that SvPV and friends would automatically stringify such an object. Otherwise, practically any kind of perl extension could be crashed by passing it one, no? But Util.xs::util_elog() expects an SV and doesn't check whether or not it actually has one. I've found a few other ways of crashing this call (e.g. by passing a typeglob), so maybe we need to test that we actually have an SV. I think SvOK() is what we'd use for that - perl gurus please confirm. I looked at that last night but it appeared that SvOK would be perfectly happy. (Didn't actually try it, though, I was just eyeballing the flags in gdb.) I tested it and you're right, it doesn't help. I don't see what else we can do about it. There doesn't appear to be any test for an SV in the API. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Wed, Jan 4, 2012 at 13:13, Andrew Dunstan and...@dunslane.net wrote:
On 01/04/2012 12:56 PM, Tom Lane wrote:
I looked at that last night but it appeared that SvOK would be perfectly
happy. (Didn't actually try it, though, I was just eyeballing the flags
in gdb.)
I tested it and you're right, it doesn't help. I don't see what else we can
do about it. There doesn't appear to be any test for an SV in the API.
I think about the best we can do is something along the lines of:
sv2cstr()
{
...
if (Perl_vverify(sv))
return utf_u2e(SvPV(sv));
...
}
I dont the the utf_u2e is strictly needed (other than that it strdups)
as I don't think versions can have utf8 chars, or at least that $^V
will not have utf8 chars (and even if it did it would only cause
problems if they had codepoints in 128 255).
We would still have issues with typeglobs...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
Andrew Dunstan and...@dunslane.net writes: On 01/04/2012 12:56 PM, Tom Lane wrote: I looked at that last night but it appeared that SvOK would be perfectly happy. (Didn't actually try it, though, I was just eyeballing the flags in gdb.) I tested it and you're right, it doesn't help. I don't see what else we can do about it. There doesn't appear to be any test for an SV in the API. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/04/2012 03:56 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 01/04/2012 12:56 PM, Tom Lane wrote:
I looked at that last night but it appeared that SvOK would be perfectly
happy. (Didn't actually try it, though, I was just eyeballing the flags
in gdb.)
I tested it and you're right, it doesn't help. I don't see what else we
can do about it. There doesn't appear to be any test for an SV in the API.
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:
diff --git a/src/pl/plperl/Util.xs b/src/pl/plperl/Util.xs
index 7d0102b..0785e2e 100644
--- a/src/pl/plperl/Util.xs
+++ b/src/pl/plperl/Util.xs
@@ -41,7 +41,7 @@ do_util_elog(int level, SV *msg)
PG_TRY();
{
- cmsg = sv2cstr(msg);
+ cmsg = sv2cstr(newSVsv(msg));
elog(level, %s, cmsg);
pfree(cmsg);
}
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
Andrew Dunstan and...@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 9066Perl_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 0x0038c30c7003 in Perl_sv_utf8_upgrade_flags_grow (my_perl=0x17f3170, sv=0x18b6c50, flags=2, extra=0) at sv.c:3228 #2 0x0038c30c7778 in Perl_sv_2pvutf8 (my_perl=0x17f3170, sv=0x18b6c50, lp=0x7fffb0c8e370) at sv.c:3079 #3 0x7f4308447614 in sv2cstr (sv=0x18b6c50) at plperl_helpers.h:54 #4 0x7f430844771f in do_util_elog (level=18, msg=0x18b6c50) at Util.xs:44 #5 0x7f4308447bdc in XS__elog (my_perl=0x17f3170, cv=0x181e008) at Util.xs:105 #6 0x0038c30b548f in Perl_pp_entersub (my_perl=0x17f3170) at pp_hot.c:3046 #7 0x0038c30ac796 in Perl_runops_standard (my_perl=0x17f3170) at run.c:41 #8 0x0038c30480ae in Perl_call_sv (my_perl=0x17f3170, sv=0x19843e0, flags=10) at perl.c:2647 #9 0x7f4308440f3e in plperl_call_perl_func (desc=0x7fffb0c8e8b0, fcinfo=0x7fffb0c8fe10) at plperl.c:2018 #10 0x7f430843fa99 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/04/2012 05:05 PM, Tom Lane wrote: 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 ... Of course it is. It wasn't meant as a solution but as validation of your suspicions about the nature of the problem. (The leakiness could be solved, though.) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On Jan 4, 2012, at 2:48 PM, Andrew Dunstan wrote: That's kinda grotty ... and leaky ... Of course it is. It wasn't meant as a solution but as validation of your suspicions about the nature of the problem. (The leakiness could be solved, though.) From #p5p on irc.perl.org: [10:58pm]dg:interesting, so SvPV() handles string overloading, but SvPVutf8() doesn't, yet: Like CSvPV, but converts sv to utf8 first if necessary. [10:58pm]dg:oh, only for readonly objects [10:58pm]dg:probably why no-one has noticed, as version is probably the only readonly thing with string overloading [11:08pm]TonyC:it doesn't need string overloading [11:09pm]TonyC:https://gist.github.com/1562734 [11:12pm]TonyC:theory: using sv_mortalcopy() instead of newSVsv() should prevent the leak in that workaround, assuming there's no FREETMPS between the call and use of the return value Useful? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
On 01/04/2012 06:15 PM, David E. Wheeler wrote: [11:12pm]TonyC:theory: using sv_mortalcopy() instead of newSVsv() should prevent the leak in that workaround, assuming there's no FREETMPS between the call and use of the return value That's the solution to leakiness I had in mind. Tom said: 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. How do we tell if it's readonly? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl Does not Like vstrings
Andrew Dunstan and...@dunslane.net writes: Tom said: 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. How do we tell if it's readonly? SvREADONLY(sv) macro. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
