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
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);'
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
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 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
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,
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
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 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,
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
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?
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
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
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
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.
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
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:
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
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
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
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
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
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
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
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
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
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:
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:
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?
29 matches
Mail list logo
