On 01/04/2012 03:56 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@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
