develooper Front page | perl.perl5.porters | Postings from January 2012

[perl #108994] certain objects crash SvPVutf8()

Thread Next
Father Chrysostomos via RT
January 24, 2012 21:35
[perl #108994] certain objects crash SvPVutf8()
Message ID:
On Tue Jan 24 19:05:18 2012, rjbs wrote:
> This is a bug report for perl from,
> generated with the help of perlbug 1.39 running under perl 5.14.2.
> -----------------------------------------------------------------
> [Please describe your issue here]
> I am reporting thus bug on behalf of Andrew Dunstan
> <>
> He is a programmer with PostgreSQL.
> Essentially, the problem is the one seen in this email thread:
> <>
> and this one:
> <>
> and this:
> <>
> In a nutshell, if we pass certain objects to SvPVutf8() we get a
> crash. If we copy them first using newSVsv() we don't get a crash.
> Things we know of that have this problem include $^V and typeglobs.
> Not sure if there are others. Of course, a crash in a database server
> (this is a perl interpreter that runs inside the database server) is a
> pretty bad thing. Currently we're working around it by unconditionally
> copying the argument with newSVsv(), but we'd like to reduce the
> overhead of that by knowing exactly when we need to do it. And from
> our POV getting a crash at all is a bug in Perl.

Having a quick look at the code, I can’t see how it would crash, but I
do see how it would produce errors.

SvPVutf8 tries to force its argument to a string, even if it’s read-only.

Even if one works around the errors/crashes, what it’s doing is just
wrong, so I would suggest this (which SvPVutf8 itself *should* be doing):

if ((SvTHINKFIRST(sv) && !SvIsCOW(sv)) || isGV_with_GP(sv))
    sv = sv_mortalcopy(sv);

That will prevent SvPVutf8 from making any user-visible changes to sv.


Father Chrysostomos

via perlbug:  queue: perl5 status: new

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About