Front page | perl.perl5.porters |
Postings from January 2012
On Tue Jan 24 19:05:18 2012, rjbs wrote:
> This is a bug report for perl from rjbs@cpan.org,
> 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
> <andrew@dunslane.net>
>
> He is a programmer with PostgreSQL.
>
> Essentially, the problem is the one seen in this email thread:
> <http://archives.postgresql.org/pgsql-hackers/2012-01/msg00149.php>
> and this one:
> <http://archives.postgresql.org/pgsql-hackers/2012-01/msg00287.php>
> and this:
> <http://archives.postgresql.org/pgsql-hackers/2012-01/msg00295.php>
>
> 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
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108994
Thread Next