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
On 01/05/2012 01:09 PM, Tom Lane wrote:
Andrew Dunstan 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 l
Andrew Dunstan 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
c
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
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 rev
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 scal
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
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
"David E. Wheeler" 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 elo
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 a
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
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 resu
Andrew Dunstan writes:
> On 01/04/2012 08:32 PM, Tom Lane wrote:
>> Andrew Dunstan 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 wond
On 01/04/2012 08:32 PM, Tom Lane wrote:
Andrew Dunstan 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'
Andrew Dunstan 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
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:
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:5
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
Andrew Dunstan 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 READ
On 01/04/2012 03:56 PM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 el
On Wed, Jan 4, 2012 at 13:13, Andrew Dunstan 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,
On 01/04/2012 12:56 PM, Tom Lane wrote:
Andrew Dunstan 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. Othe
Andrew Dunstan 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 exte
On 01/04/2012 11:15 AM, Tom Lane wrote:
Andrew Dunstan 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 th
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
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 subscript
Andrew Dunstan 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 c
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:59
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]
$
Best,
David
smime.p7s
Des
30 matches
Mail list logo
